SAGA 4.0 - Bund.de

Transcription

SAGA 4.0 - Bund.de

SAGA
Standards and Architectures for eGovernment Applications
Version 4.0
March 2008
2
SAGA 4.0
Reprint, even in part, subject to approval
This volume was prepared by the Federal Ministry of the Interior
in co-operation with ]init[ AG and
Fraunhofer-Institut für Software- und Systemtechnik (ISST).
Homepage and download of the digital version: http://www.cio.bund.de/saga
mail to: IT2@bmi.bund.de
SAGA 4.0
SAGA
Version 4.0
March 2008
Published by
the Federal Ministry of the Interior
3
4
SAGA 4.0
SAGA 4.0
Word of thanks
The Federal Ministry of the Interior and the SAGA authors would like to thank the
representatives from the federal states and municipalities in the KoopA-SAGA project
group, the representatives from the central IT service providers of the federal
administration along with all the members of the SAGA expert group for their support
during the preparation of this version of SAGA.
We would also like to extend our thanks to all those who have made use of the SAGA forum
and the SAGA contact form and whose committed comments constituted a valuable
contribution towards updating the document.
5
6
SAGA 4.0
Introduction:
This document presents in concise form widely used standards, processes, and methods of
state-of-the-art IT development for eGovernment applications. Due to the nature of this
subject, experts in this sector use many abbreviations and, in most cases, English acronyms.
Some of these names are protected by copyright and/or are registered trademarks, or are
products of certain manufacturers or standardization organizations that are protected at
national and international level.
In the interest of a simple structure, copyright and source references of this kind were
generally omitted. The use of a "name" or abbreviation in this document does not
mean that they are free from copyrights or intellectual property rights of third
parties.
Furthermore, neither the editor, the authors nor the experts consulted can accept any
responsibility for the technical functioning, compatibility or completeness of the standards
discussed. This version 4.0 was published in October 2007. Please send any comments,
amendments or corrections to: Bundesministerium des Innern, Referat IT2. These
comments, amendments or corrections can also be published on the SAGA forum at
http://www.cio.bund.de.
Version numbers are stated when they are relevant in the specific context discussed. If no
version numbers of standards are stated, the version which is most stable from a market
point of view should be used, even though this may not necessarily be the latest version.
The authors permit the further use of this document - even in part - on condition that it is
quoted as the source.
A general demand for SAGA conformance is not enough in order to achieve the
goals of SAGA. Due to the complexity of the document, a general demand leaves too
much room for interpretation and misunderstanding. This makes it difficult for the
supplier to fulfil the requirements and for the customer to check that requirements are
fulfilled. To find out more about the correct handling of SAGA conformance, please refer
to section 2.4 on page 25, and for further assistance, go to: http://www.cio.bund.de/saga.
In the time since the first publication of SAGA 4.0 the website http://www.kbst.bund.de/saga
was moved to http://www.cio.bund.de/saga. Therefore some of the links given in this
document are no longer valid. For information on SAGA please refer to
http://www.cio.bund.de/saga.
SAGA 4.0
7
Table of Contents
0
Status, revision history and outlook..................................................................................................9
0.1
Amendments to version 3.0................................................................................................................9
0.2
Future issues.........................................................................................................................................10
1
Introduction..........................................................................................................................................11
1.1
Background...........................................................................................................................................11
1.2
Readers of this document...................................................................................................................11
1.3
Aims........................................................................................................................................................12
1.4
Tasks.......................................................................................................................................................12
1.5
Basic principles for eGovernment applications.............................................................................13
1.6
Relationships with other eGovernment documents.....................................................................13
1.7
The evolution process.........................................................................................................................17
1.8
Structure of the document.................................................................................................................18
2
Fundamentals of SAGA.......................................................................................................................19
2.1
Scope of validity and binding effect of SAGA..................................................................................19
2.2
Minimum requirements with regard to the openness of standards.........................................20
2.3
Classification and life cycles of standards.......................................................................................20
2.4
SAGA conformance.............................................................................................................................25
3
Architecture model for eGovernment applications......................................................................31
3.1
Overview...............................................................................................................................................31
3.2
Enterprise viewpoint..........................................................................................................................32
3.3
Information viewpoint.......................................................................................................................33
3.4
Computational viewpoint.................................................................................................................34
3.5
Engineering viewpoint......................................................................................................................34
3.6
Technology viewpoint........................................................................................................................34
4
Enterprise viewpoint: Fundamentals of eGovernment...............................................................35
4.1
Definitions of eGovernment in Germany.......................................................................................35
4.2
The philosophy underlying eGovernment.....................................................................................36
4.3
Strategic goals......................................................................................................................................37
4.4
Organizational requirements...........................................................................................................41
4.5
Legal frame of reference....................................................................................................................45
4.6
Processes in eGovernment................................................................................................................49
4.7
Modules for the implementation of eGovernment applications...............................................52
5
Information viewpoint: Standardization of data models............................................................55
5.1
Levels of interoperability...................................................................................................................55
5.2
Purpose of standardizing data models...........................................................................................56
5.3
The Deutschland-Online "Standardisierung" [Standardization] project.................................57
5.4
Support for data model developers.................................................................................................59
6
Computational viewpoint: Reference software architecture....................................................65
6.1
General requirements for software applications..........................................................................65
6.2
Implementation options and architecture paradigms................................................................67
8
SAGA 4.0
6.3
7
Reference software architecture for eGovernment applications...............................................72
Engineering viewpoint: IT service management and reference infrastructure.....................79
7.1
IT Service Management with the ITIL..............................................................................................79
7.2
Design of an eGovernment infrastructure.....................................................................................84
7.3
Networks as the link between an infrastructure and external services and users..................88
7.4
Access to external services................................................................................................................88
8
Technology Viewpoint: Standards for IT architecture and data security..................................91
8.1
IT security concept..............................................................................................................................91
8.2
Process models....................................................................................................................................95
8.3
Data models.........................................................................................................................................96
8.4
Application architecture...................................................................................................................98
8.5
Client....................................................................................................................................................101
8.6
Presentation.......................................................................................................................................105
8.7
Communication.................................................................................................................................121
8.8
Backend...............................................................................................................................................130
8.9
Encryption..........................................................................................................................................132
8.10
Electronic signature..........................................................................................................................133
8.11
Smartcards..........................................................................................................................................135
8.12
Long-term archiving.........................................................................................................................136
Appendix A
References..........................................................................................................................................139
Appendix B
Overview of Classified Standards....................................................................................................143
Appendix C
Abbreviations.....................................................................................................................................153
SAGA 4.0
0
9
Status, revision history and
outlook
0.1
Amendments to version 3.0
This document is a revised version of SAGA, version 3.0. The following changes have been
made:
In chapter 2 "Fundamentals of SAGA", the names of the lists for the extended classification
of technical standards outside the document (White List, Grey List, Black List) were replaced
with new names (List of Suggestions, Right of Continuance List, Negative List)1.
Chapter 4 "Enterprise viewpoint: Fundamentals of eGovernment" has been re-organized.
The terms "eGovernment" and "service" are now more clearly defined2. This chapter was
also extended to include the topics of "eGovernment 2.0"3, "Deutschland-Online"4,
"Germany as a member of the European Union"5, the "EU service directive"6 and the
"Federal government's signature projects and initiatives"7 .
Chapter 5 "Information viewpoint: Standardization of data models" was revised with a view
to the Deutschland-Online "Standardization"8 project and the topics of XGenerator 2.09 and
Core Components10.
Chapter 6 "Computational viewpoint: Reference software architecture" now also includes
sections on architecture decisions11 and information addressing the introduction of service
oriented architectures12.
Chapter 7 "Engineering viewpoint: IT service management and reference infrastructure"
introduces the "IT Infrastructure Library" (ITIL) as best practice for IT service management13.
In addition to this, the Deutsches Verwaltungsdiensteverzeichnis (DVDV) [German
Directory of Administrative Services] is presented in more detail14.
The previous chapter 8 “Technology viewpoint (part I): Standards for the IT architecture"
and chapter 9 "Technology Viewpoint (part II): Standards for data security" were combined
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Refer to section 2.3.2 "Extended classification of standards" on page 21
Refer to section 4.1 "Definitions of eGovernment in Germany" on page 35
Refer to section 4.3.1 "eGovernment 2.0 – A Federal Government programme" on page 37
Refer to section 4.3.2 "Deutschland-Online - The joint eGovernment strategy of the Federal
Government, federal-state governments and municipalities." on page 38
Refer to section "Germany as a member of the European Union" on page 43
Refer to section 4.5.4 "EU services directive – Creating a single EU market" on page 48
Refer to section "Federal Government initiatives and projects in the field of electronic
signatures" on page 46
Refer to section 5.3 "The Deutschland-Online "Standardisierung" [Standardization] project"
on page 57
Refer to section 5.4.3 "XGenerator 2.0" on page 62
Refer to section 5.4.4 "Core components" on page 63
Refer to section 6.3.1 "Architecture decisions" on page 72
Refer to section 6.3.2 "Introduction of a service oriented architecture" on page 73
Refer to section 7.1 "IT Service Management with the ITIL" on page 79
Refer to section 7.4.1 "Deutsches Verwaltungsdiensteverzeichnis [German Directory of
Administrative Services]" on page 88
10
SAGA 4.0
to form chapter 8 "Technology viewpoint: Standards for IT architecture and data security".
Moreover, products and implementations were persistently replaced by the underlying
standards. The previous positive list of supported plug-ins was replaced by a list of
requirements which plug-ins should fulfil in the federal administration's eGovernment
applications. The topics of "IP telephony"15 and "Registries"16 were re-introduced and the
topic of "Smartcards"17, which was already addressed in SAGA 3.0, was dealt with in more
detail.
SAGA 4.0 no longer features a separate appendix for the one-for-all offers (OFA offers) by the
federal administration. The OFA offers will be soon described and will be updated outside of
SAGA on the KBSt18 homepage and/or on the homepage of the individual OFA offers,
respectively. The definitions of OFA service, OFA system, infrastructure and OFA concept
were moved to chapter 619.
Furthermore, this version also features a response to the further development of standards.
Standards were accepted from the List of Suggestions (former White List), the classification
of existing standards was changed and standards were moved from the document to the
Right of Continuance List (former Grey List20).
0.2
Future issues
The following topics are to be examined and dealt with in more detail in the next version of
SAGA:
a. Development and standardization of process and data models
b. IT service management on the basis of the "IT Infrastructure Library" (ITIL) v3.0
c. Long-term archiving of dynamic information from databases and websites
d. Communication per instant messaging and chat
e. Exchange and visualization of 3D data
Besides the SAGA document, the Federal Ministry of the Interior also provides additional
information, links and tools on the web21.
15
16
17
Refer to section 8.7.4 "IP telephony" on page 125
Refer to section 8.8.1 "Directory services and registries" on page 130
Refer to section 8.11.2 "Contactless smartcards" on page 135 and section 8.11.3 "Reader units
and interfaces for smartcards" on page 136
18 Refer to http://www.kbst.bund.de/efa
19 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76
20 With regard to the definition of White List and Grey List, refer to section 2.3.2 on page 21
21 Refer to http://www.kbst.bund.de/saga
SAGA 4.0
1
1.1
11
Introduction
Background
In an effort to create a more modern and service-orientated administration, the Federal
Government is implementing more and more administration processes electronically. The
application of eGovernment is making it possible for citizens, business and administrations
to handle matters both faster and more efficiently. Standards are needed in order to enable
these many different applications for the future and accessible for all. This is guaranteed by
the Standards and Architectures for eGovernment Applications (SAGA) guideline.
Shortly after the launch of the nation-wide BundOnline Initiative, the Co-ordinating and
Advisory Agency of the Federal Government for Information Technology in the Federal
Administration (KBSt) made this document available for the first time in 2002. Since then,
SAGA has been helping public agencies to achieve the goal of the initiative and to offer
more than 400 online services with Internet capability.
On the basis of this success, the SAGA expert group continuously accompanies work on the
standards. In this version 4.0, central IT service providers from the federal administration
were involved for the first time in updating the guideline. The latest developments and
experience are being added to the document through the discussion in the public SAGA
forum. In close co-operation with a KoopA-SAGA project group22, the specific requirements
of the federal states and municipalities are also being included. With this knowledge, the
SAGA authors regularly prepare an updated version with the Federal Ministry of the Interior
which is in charge of content.
A host of completed projects has now been orientated towards the state-of-the-art and
investment-safe standards and technologies recommended by SAGA. Many federal
agencies use SAGA to plan and implement their IT projects, so that they can shape the
interoperability of the various planned and existing applications.
Widespread acceptance and especially growing interest among federal states and
municipalities are proof that SAGA is becoming increasingly important for eGovernment in
Germany. In this version 4.0, SAGA once again offers a guideline for the economic and
future-orientated implementation of IT projects in administrations.
1.2
Readers of this document
SAGA is primarily designed for decision-makers in the fields of organization, information
technology and eGovernment teams in German administrations. The document is a
guideline that serves as an orientation aid when it comes to developing concepts for
technical architectures and general technical concepts for individual IT applications.
22 KoopA ADV = Co-operation Committee for Automatic Data Processing for the Federalgovernment, Federal-state Government and Municipal Administration Sector
12
SAGA 4.0
Application developers should feel free to seek further detailed solutions whenever the
standards and solution proposals presented herein are not sufficient for the
implementation of technical requirements.
The Federal Government also sees its initiative as a contribution towards the development
of eGovernment in Germany. The experience gained within the scope of the initiative
should help to promote nation-wide, inter-agency eGovernment offers.
1.3
Aims
SAGA pursues the following aims:
a. Interoperability – Warranting co-operation between various eGovernment
applications in order to effectively exchange information between the Federal
Government, citizens, businesses and partners of the Federal Government
b. Reusability – re-use of process and data models, systems, services and components in
various eGovernment projects in order to generate synergies
c. Openness – Inclusion of open standards in eGovernment applications in order to
promote their long-term usability23
d. Reduction of costs and risks – Considering investment-safe developments on the
market and in the field of standardization
e. Scalability – Ensuring the usability of applications as requirements change in terms of
volume and transaction frequency
1.4
Tasks
SAGA pursues a comprehensive standardization approach for Germany's administrations in
order to achieve the following goals.
Defining technical Standards and Architectures for eGovernment Applications
The technical standards and architectures cover all the levels and elements relevant for
eGovernment. They form the basis for the interoperability and compatibility of the
eGovernment applications to be developed.
Standardizing processes and data in administrations
In order to achieve interoperability and compatibility of eGovernment applications, it is
necessary to create a basis for standardizing processes and data in Germany's
administrations. In an effort to support this, systems and services are described on the KBSt
website which can be used as modules (one-for-all offerings24) in eGovernment applications.
23 Refer to section 2.2 "Minimum requirements with regard to the openness of standards" on
page 20
24 OFA offering and networks: http://www.kbst.bund.de/efa
SAGA 4.0
1.5
13
Basic principles for eGovernment
applications
eGovernment applications are designed to fully reach their target groups. This is why it
should be possible to access all the functions irrespective of the users' selected platform, the
configuration of the user systems or the abilities of the users. eGovernment applications
must be orientated towards the requirements and needs of the target groups.
On the basis of these preconditions, the following basic principles are laid down for
eGovernment applications:
a. eGovernment applications primarily use the web browser as the front-end, unless the
services to be implemented cannot be reasonably handled via a browser.
b. They do without active contents so that users are not forced to reduce the browser's
security settings and thus to make damage by invisible websites possible, or at least use
only signed and quality-secured applications of the type contemplated in the section
8.5.1 "Access to information with computers” on page 101.
c. eGovernment applications do not store any program parts or data on the users'
computers beyond the users' control25.
1.6
Relationships with other eGovernment
documents
Trials with standards and architectures for eGovernment have been underway for some
years now in Germany and in other countries26. Experience from these trials and
international exchange help make it easier to define and implement SAGA.
SAGA is published as part of the KBSt publication series which also includes, for example,
the "V Model XT", the "Migrationsleitfaden" [Migration Guide] and the "DOMEA-Konzept"
[DOMEA concept]. The documents of these series are adjusted to each other when updates
are released. This means that SAGA supersedes contents and information of older
documents and that new documents consider the contents and information of the latest
SAGA version. A broad-based co-ordination process accompanies any SAGA update in order
to avoid conflicts with valid documents.
E-Government-Handbuch [eGovernment manual]
In order to promote the Federal Government's eGovernment initiative – such as the
BundOnline 2005 Initiative that was completed in 2005 – and to support federal-state and
municipal agencies, the E-Government-Handbuch27 [eGovernment manual] is prepared
under the leadership of the German Federal Office for Information Security. This manual is
25 The automatic installation of software playing certain music CDs is one negative example
of non-requested saving of programs on computers.
26 Refer to the respective documents and publications in the UK [e-GIF], the United States of
America [FIPS-PUBS], Australia [APEC] and Europe [IDABC].
27 Refer to http://www.bsi.bund.de/fachthem/egov/3.htm
14
SAGA 4.0
designed as a reference manual and central information exchange for issues related to
eGovernment.
The E-Government-Handbuch [eGovernment manual] is a modular compilation of material
that covers a broader range of issues and topics than SAGA. As far as identical issues are
addressed, the E-Government-Handbuch [eGovernment manual] does so in a more
concrete manner. This is why certain modules of the eGovernment manual are referenced
from within SAGA28. SAGA sets forth guidelines, whilst the E-Government-Handbuch
[eGovernment manual] explains the implementation of these guidelines and offers
practical advice.
In mid-February 2003, SAGA became part of the E-Government-Handbuch [eGovernment
manual]. It is the module of the manual with the strongest binding effect. All the other
modules are designed to ensure conformity with SAGA.
When examining the focal issue of "IT and IT security", the study titled "Sichere Integration
von E-Government-Anwendungen(SIGA)"29 [Secure integration of eGovernment
applications] was drafted. The aim of this study is to adapt the technologies presented in
SAGA for the business logic level, to identify correlations and to provide valuable,
independent assistance for IT experts and decision makers.
IT-Grundschutz-Kataloge und -Standards [IT baseline protection catalogues and standards]
In order to draft IT security concepts for normal security requirements, BSI recommends
standard security measures for typical IT systems in its IT-Grundschutz30 [IT baseline
protection]. The aim of these IT-Grundschutz [IT baseline protection] requirements is –
through the suitable application of standard security measures at organizational,
manpower, infrastructure and technical levels – to achieve a security level for IT systems
which is reasonable and sufficient for normal protection requirements and which can serve
as a basis for IT systems and applications with high security requirements.
IT-Grundschutz [IT baseline protection] includes the BSI-Standards31 [BSI standards] for IT
security management and the IT-Grundschutz-Kataloge32 [IT baseline protection
catalogues] which replace the previous IT-Grundschutzhandbuch [IT Baseline Protection
Manual]. The BSI-Standards [BSI standards] are broken down into:
a. BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS)33
[BSI standard 100-1: Management systems for Information Security],
b. BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise34
[BSI standard 100-2: IT baseline protection approach] and
28 Refer, for instance, to section 8.1.4 "Implementation of the security concept" on page 93 and
section 8.5.4 "Technologies for authentication" on page 104
29 Refer to [SIGA]
30 Refer to http://www.it-grundschutz.de/
31 Refer to http://www.bsi.de/literat/bsi_standard/
32 Refer to http://www.bsi.de/gshb/deutsch/
33 Refer to http://www.bsi.bund.de/literat/bsi_standard/standard_1001.pdf
34 Refer to http://www.bsi.de/literat/bsi_standard/standard_1002.pdf
SAGA 4.0
15
c. BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz35
[BSI standard 100-3: Risk analysis on the basis of IT baseline protection].
The application of IT-Grundschutz [IT baseline protection] is supported in SAGA; the BSIStandards [BSI standards] for IT security management and the IT-Grundschutz-Kataloge [IT
baseline protection catalogues] are defined as mandatory standards36.
Barrierefreie Informationstechnik-Verordnung – BITV [barrier-free information technology
ordinance]
The ordinance on the creation of barrier-free information technology pursuant to section 11
of Behindertengleichstellungsgesetz [law on equal opportunities for the disabled]
(Barrierefreie Informationstechnik-Verordnung – BITV)37, which came into effect on 24 July
2002, is referenced in SAGA and is defined as a mandatory standard with regard to the
implementation of the presentation and client layers38.
V-Modell XT
The V-Modell XT39 is the binding process model throughout the federal administration for
the development of IT systems for the federal authorities. The V-Modell XT must be
considered in strategic planning and project management efforts and in conjunction with
the implementation of eGovernment applications.
Used as a guideline for planning and implementing development projects, this model
defines the results to be achieved in a project whilst considering the entire system lifecycle.
At the same time, it describes the concrete approach with which these results are to be
achieved. Furthermore, the V-Modell XT also defines the responsibilities of each project
participant. It hence serves as a basis for contracts, as a guideline for work and as a basis for
communication.
The V-Modell XT is subject to ongoing upgrading in the form of releases.
IT Infrastructure Library – ITIL
When it comes to the efficient and reliable management of IT processes, the "IT Infrastruc
ture Library" (ITIL), as a process library which supplies best practices, has now become
established as the globally accepted defacto standard. This is why KBSt has issued a series of
publications concerning the application of ITIL40.
In ITIL, Service Management addresses a general-interest topic that must be considered
from the beginning of the lifecycle of an IT application. This results in synergies for the
approach according to the other standards which are presented in a KBSt study41.
35
36
37
38
39
40
41
Refer to http://www.bsi.de/literat/bsi_standard/standard_1003.pdf
Refer to chapter 7 on page 79 and section 8.1 on page 91
Refer to http://bundesrecht.juris.de/bitv/
Refer to sections 4.5.3 on page 47 and 8.6.1 on page 105
Refer to http://www.kbst.bund.de/v-modell
Refer to http://www.kbst.bund.de/itil
Refer to "ITIL und Standards für IT-Prozesse" [ITIL and Standards for IT Processes], version
1.0.1, KBSt Letter No. 1/2006, October 2006
16
SAGA 4.0
During the preparation of SAGA 4.0, an upgraded ITIL, version 3.0, was issued. In order to
use a tried-and-tested approach as a basis and to be able to refer to German literature, ITIL
version 2.0, which is supported by KBSt documents, is presented in the Engineering
Viewpoint (chapter 7)42.
Migrationsleitfaden [Migration guide]
This guide43 is designed to offer both strategic/economic and detailed technical decisionmaking aids for forthcoming or recently completed migration projects. The focus of this
guide is the replacement of proprietary products both with open source software (OSS) and
– where necessary – future generations of proprietary products. Agency-specific scenarios
are developed and different migration alternatives are discussed.
The Migrationsleitfaden [migration guide] was developed with a view to SAGA version 2.1 as
far as relevant interfaces were concerned. SAGA updates will have no repercussions on the
statements made.
DOMEA-Konzept [DOMEA concept]
DOMEA44 stands for "Dokumentenmanagement und elektronische Archivierung"
[document management and electronic archiving] in IT-based workflows. The aim of this
concept is to introduce the electronic file. Physical files are to be replaced with workflows at
public agencies in the form of fully electronic, media-consistent procedures. The electronic
file is subject to the same legal and functional requirements as conventional files. Since the
publication of the concept in 1999, DOMEA has become an established standard for
electronic workflows at federal, federal-state and municipal agencies. For product
manufacturers, the DOMEA-Konzept [DOMEA concept] is a major source of information
when it comes to identifying the demands of public administrations which are considered
when products are developed further.
Besides the organizational concept and the resultant requirements catalogue, the modular
concept includes further elements which address specific issues of the organizational
concept in more detail.
The requirements catalogue of the DOMEA concept translates organizational requirements
into functional requirements which are orientated towards the SAGA standards on the one
hand whilst also influencing the updating process of the SAGA document on the other. The
DOMEA concept describes the relevant requirements for software products related to the
area of electronic workflow management. These requirements are in some respects even
more demanding than SAGA and hence do not jeopardise SAGA conformity.
42 Refer to section 7.1 "IT Service Management with the ITIL" on page 79
43 Refer to http://www.kbst.bund.de/migrationsleitfaden
44 Refer to http://www.kbst.bund.de/domea
SAGA 4.0
1.7
17
The evolution process
Standards and architectures in SAGA undergo a defined process before they are included:
a. Proposal for standards and architectures in the public discussion forum, via the contact
form, from the SAGA expert group, the KoopA-SAGA project group, the central IT
service providers from the federal administration or the SAGA authors
b. Examination of proposals by the SAGA authors
c. Discussion in the SAGA expert group on the standards and architectures which were
found to be suitable by the SAGA authors
d. Acceptance of proposals in a KBSt resolution on the basis of the discussion between the
SAGA authors and the SAGA expert group
e. Inclusion of the accepted standards and architectures in SAGA by the SAGA authors as
soon as the resolution has been made by the KBSt
SAGA is updated at regular intervals, amended to reflect the latest developments and
findings and published on the homepage of the KBSt45 and within the scope of the EGovernment-Handbuch46 (eGovernment Manual).
If problems occur that cannot be resolved using known standards, requests for proposals
(RFPs) are sent to the SAGA expert group in order to identify possible solutions.
Public discussion forum
A public forum at: http://www.kbst.bund.de/saga-forum enables Internet users to register
and discuss issues related to the application and further development of SAGA. The results
of the discussions are evaluated and, if suitable, are considered in the next version of the
SAGA document.
Contact form
The SAGA homepage provides a contact form47 for SAGA users. This form can be used to
send structured ideas and queries directly to the SAGA authors.
The SAGA expert group
The KBSt has established an expert group48 comprising representatives from business,
science and administration and appoints the members. This expert group is involved in the
updating process at regular intervals or whenever there is reason for involvement.
The KoopA-SAGA project group and central IT service providers of the federal administration
The Co-operation Committee for Automatic Data Processing for the Federal-government,
Federal-state Government and Municipal Administration Sector (KoopA ADV) delegates
45
46
47
48
Refer to http://www.kbst.bund.de/saga
Refer to http://www.bsi.bund.de/fachthem/egov/3.htm
Refer to http://www.kbst.bund.de/saga-kontaktformular
Refer to http://www.kbst.bund.de/saga-expertenkreis
18
SAGA 4.0
representatives from the federal states and municipalities to accompany the further
development of SAGA in workshops. The SAGA authors draft a catalogue of questions for
proposed amendments which are answered by the participants and supplemented by their
own proposals. In analogy to this approach, the requirements of the central IT service
providers of the federal administration are collected in workshops and written exchanges
and taken into consideration in the updating of the document.
SAGA examination report
The proposals put to the SAGA authors in the public forum, via the contact form, in the
SAGA expert group, in the KoopA-SAGA project group and by the central IT service
providers of the federal administration are listed in a SAGA examination report49 and the
result of the examination is documented. The reasons for acceptance or rejection are
explained.
1.8
Structure of the document
Chapter 2 addresses issues concerning the scope of validity and binding nature of SAGA.
Furthermore, this chapter also presents minimum requirements concerning the openness
of standards as well as definitions of the different classification of standards. In addition to
this, the subject of SAGA compliance of eGovernment applications is dealt with.
Chapter 3 describes the architecture model for eGovernment applications. This model was
also adopted for the description of eGovernment in Germany. Accordingly, the following
chapters 4 to 8 present viewpoints of the architecture model on eGovernment in its totality.
a. Chapter 4 documents the goals of German eGovernment, the players, roles, frames of
reference, guidelines and forms of interaction as well as the aims with regard to
standardized processes (enterprise viewpoint).
b. Chapter 5 describes the activities for defining standardized data models and help for
developers of data models (information viewpoint).
c. Chapter 6 contains a reference software architecture, which can be used to develop
architectures for concrete eGovernment applications, and information for integrating
modules, such as the one-for-all offerings (OFA offerings), into the software architecture
(computational viewpoint).
d. Chapter 7 describes the IT Service Management and requirement of eGovernment
computer centres for operating eGovernment applications, as well as the use of
modules, such as OFA offers, in an existing infrastructure (engineering viewpoint).
e. Chapter 8 defines the standards, technologies and methods for the IT architecture and
for ensuring data security (technology viewpoint).
Appendix A contains a list of references and Appendix B provides an alphabetic list of the
standards referred to in chapter 8. Appendix C finally presents a list of the abbreviations
used in SAGA.
49 Refer to http://www.kbst.bund.de/saga
SAGA 4.0
2
2.1
19
Fundamentals of SAGA
Scope of validity and binding effect of
SAGA
Around 400 services have so far been identified for the different federal administrations.
The services can be classified, for instance, according to their target groups50; refer to Fig. 21.
G2C – Government to Citizen
(Interaction between the
administration and citizens)
G2B – Government to Business
(Interaction between the
administration and business)
G2G – Government to Government
(Interaction between administrations)
• BA: Job exchange
• DRV: Calculation and payment of
pensions
• BMAS: Provision of information
• DWD: Weather forecast and
meteorological advice
• BpB: Provision of information and
order handling
• BA: Job exchange
• BeschA: Procurement
• BBR: Procurement for
construction and civil engineering
projects
• BMBF: Project-related subsidies
• BMWi: Subsidy programmes
• KBA: Central traffic and motor
vehicle register
• BBR: Procurement for construction
and civil engineering projects
• BMF: Management of FederalGovernment properties
• BAköV: Further training and
education
• BZR: Federal Central Criminal
Register
Figure 2-1: Selected Federal Government services
SAGA's scope of validity covers the federal administration and software systems with
interfaces between federal authorities and federal-state and/or municipal authorities in
order to support the services listed above.
SAGA includes recommendations concerning standards and architectures for
eGovernment applications. The term "eGovernment applications" refers to software
systems which are used to fulfil services of the Federal Government or which actively
support the fulfilment of such services. In the case of systems with no direct interfaces with
eGovernment, migration is recommended on condition of a positive outcome of the costto-benefit analysis. Whenever possible, the standard software51 to be bought should be
primarily products or product versions which are compatible with SAGA recommendations.
Furthermore, SAGA considers only those areas which have a major influence on the
aforementioned objectives52 rather than all the elements of a technical architecture.
The Federal Ministry of the Interior recommends that SAGA be considered in invitations to
tender for eGovernment applications for the federal administration in the manner
described in section 2.4.1 "Definition of conformance" on page 25, and section 2.4.2 "SAGA
conformance in invitations to tender" on page 26.
50 Refer to the section 4.6.2 on "Relationships in interaction" on page 49.
51 Software that is simply installed and configured
52 Refer to section 1.3 "Aims" on page 12.
20
SAGA 4.0
The federal ministries lay down rules for the binding effect of SAGA within their areas of
competence.
2.2
Minimum requirements with regard to
the openness of standards
One aim of SAGA is the use of open standards in eGovernment applications, refer to section
1.3 "Aims" on page 12. There are currently many different definitions for an "open
standard", however, there is no one generally valid definition accepted by all. Various
standardization committees have issued definitions which are essentially the same in terms
of how a standard emerges, its documentation and application. However, opinions do differ
when it comes to the type of standardization organization and the license cost system of a
standard. These issues are rated differently by the various committees (e.g. IDABC, ETSI,
DIN, CEN, ISO). SAGA is not designed as a forum for these discussions, instead it is to remain
a practice-based recommendation. This is why "minimum requirements" were defined for
the openness of standards which will also serve as an evaluation basis for accepting or
rejecting a standard in SAGA.
The minimum requirements for the openness of standards for acceptance in SAGA are
defined as follows:
a. The standard was published and documentation of standard specifications is either free
or at most available against a nominal fee.
b. The intellectual property (for instance, in the form of patents) of a standard or of parts
of a standard must, if possible, be accessible without being contingent upon the
payment of a license fee.
c. The federal administration and the users of its services must be able to use the standard
without restriction.
d. The standard must remain published and freely usable in the future.
2.3
Classification and life cycles of
standards
2.3.1
Classification in SAGA
Standards are divided into three categories. Competing standards which are not stated
should not be used or only if absolutely inevitable; refer also to section 2.3.4 "Non-classified
standards" on page 25.
Under observation:
Standards are under observation if they are in line with the intended development trend,
are finalized and meet the minimum requirements for the openness of standards53. These
53 Refer to section 2.2 "Minimum requirements with regard to the openness of standards" on
SAGA 4.0
21
standards may not yet have proven their worth in practical application or do not meet all
the aims of SAGA; refer to section 1.3 "Aims" on page 12.
In the event that no competing mandatory or recommended standards exist in addition to
the standards under observation, such standards under observation can be used in
eGovernment applications. Only in justified exceptional cases should preference be given
to standards under observation over higher classified alternatives.
Recommended:
Standards are recommended if they have been tried and tested in practical application but
if a more suitable, mandatory standard exists or if they do not meet all the aims of SAGA.
However, minimum requirements for the openness of standards must be fulfilled and
investment security warranted.
In the event that no competing mandatory standards exist besides recommended
standards, deviations from the recommended standards are permitted in justified,
exceptional cases only.
Competing standards can be recommended parallel if they have clearly different fields of
application. The standard which is best suited for the given application must be adopted in
such cases.
Mandatory:
Standards are mandatory if they have been tried and tested in practical application and
represent the preferred solution. They are established on the market and meet all the aims
of SAGA. Such standards must be observed and applied with priority.
Competing standards can be mandatory parallel if they have clearly different fields of
application. In such cases, the standard which is best suited for the given application must
be used.
In the event that mandatory and recommended standards or standards under observation
exist parallel, the latter - i.e. standards under observation - should only be adopted in
justified, exceptional cases.
A standard classified as mandatory does not necessarily have to be used in every
eGovernment application. A mandatory standard only should be adhered to if the use of the
technology or functionality related to this standard is necessary or reasonable in view of the
requirements of the specific application.
2.3.2
Extended classification of standards
Three lists for the extended classification of standards were introduced with the publication
of SAGA 2.0 on the SAGA homepage at http://www.kbst.bund.de/saga-standards. No
standards other than those on the Right of Continuance List (former Grey List) may be given
preference over the standards classified in the SAGA document (mandatory, recommended,
page 20.
22
SAGA 4.0
under observation) – however, only if existing systems, in which these standards are already
used, are being upgraded.
List of Suggestions
The List of Suggestions (former White List) was created in order to respond promptly to new
developments and to be able to communicate these externally for information. During the
course of developing the SAGA document further, the List of Suggestions is an important
basis for including standards in SAGA.
Standards are listed in the List of Suggestions if proposals and ideas for their inclusion in
SAGA were submitted to the SAGA authors, if they have potential for use in eGovernment
applications and if these standards have not yet been classified further.
Standards in the List of Suggestions are evaluated by the SAGA authors and the SAGA expert
group. The result of this evaluation can mean acceptance of the standards in the next
version of the SAGA document, relocation to the Negative List (former Black List) or to the
Right of Continuance List (former Grey List) or also remaining on the List of Suggestions, so
that development can be observed, for instance, in the case of standards not yet finalized.
Before being published in a new SAGA version, the standards on the List of Suggestions are
again examined with regard to their suitability for inclusion.
Right of Continuance List
Standards are added to the Right of Continuance List (former Grey List) if they are no longer
included in the current SAGA version, but if they had a "recommended" or "mandatory"
status in an earlier SAGA version and/or if they were widely used in the market in the past.
When existing systems are upgraded, these standards are to be kept in effect and can
continue to be used. These standards, however, should no longer be used for new
eGovernment applications.
Negative List
Within the scope of the SAGA discussion, certain standards that were already rejected in the
past are repeatedly proposed for inclusion. The Negative List (former Black List) was set up
in order to make the results of these discussions transparent and to identify those standards
which can no longer be expected to be included in SAGA.
Standards are added to the Negative List if they were examined and rejected by both the
SAGA authors and the SAGA expert group. The standards should not be used in new or
existing eGovernment applications. Their use is only permitted if a parallel SAGAcompliant solution exists. Images, for instance, can be made available in BMP format even
though this is on the Negative List, if images are also offered at the same time in a SAGAcompliant format such as GIF.
If a standard on the Negative List is developed further and differs from the old version in
areas that were previously criticized, the version number of the negative-listed standard
must be stated. Now nothing stands in the way of the new version being included in SAGA
via the List of Suggestions (former White List).
SAGA 4.0
2.3.3
23
Life cycles of standards
Besides the standards classified in SAGA, refer to section 2.3.1 on page 20, other standards
are recorded in three different lists, refer to section 2.3.2 on page 21. Whilst the
classification of standards as "mandatory", "recommended" and "under observation" is
defined and updated in the SAGA document, presentation and ongoing updating of the
standards in the lists are carried out on the SAGA website at:
http://www.kbst.bund.de/saga-standards.
Standards can pass through different stages during their life cycle. These are illustrated in
Fig. 2-2 on page 24.
The transitions of a standard between the lists on the SAGA homepage at:
http://www.kbst.bund.de/saga-standards and the classes in the SAGA document are defined
in the following section.
1
New standards are proposed for classification by the SAGA authors, by experts or by
users; refer to section 1.7 "The evolution process" on page 17. Without any further indepth examination, these standards are initially compiled in the List of Suggestions. A
thorough examination is carried out before a new SAGA version is created. Apart from
the transfer to the SAGA document, to the Right of Continuance List or to the Negative
List, the examination may also result in the standard remaining on the List of
Suggestions. Such standards do not yet fulfil the requirements for inclusion in SAGA,
e.g. because they are not yet finalized. Their inclusion is re-examined for the next SAGA
version. Before completion of a new SAGA version, transitions 1 and 2 or 1 and 3 may also
take place in one step.
2
Standards which, following examination, are not included in SAGA are added to the
Negative List as rejected standards.
3
Standards are transferred from the List of Suggestions to the Right of Continuance List
when thorough examination suggests that these standards should not be used in new
projects, but can still be used in existing projects.
4
Following a positive examination of the respective requirements, refer to section 2.3.1
"Classification in SAGA" on page 20, standards are included in SAGA with the
classification "under observation". If the respective requirements are fulfilled, the
standard can also be directly allocated to one of the higher classes, i.e. "recommended"
or "mandatory". The transitions 4 and 5, or 4, 5 and 6, respectively, are then carried out
in one step.
5
Following successful examination of the respective requirements in SAGA, standards
with "under observation" status are classified as "recommended" in SAGA. If the
requirements are fulfilled, the standard can also be directly allocated to the higher
class, i.e. "mandatory". Transitions 5 and 6 are then carried out in a single step.
Standards which after examination still fail to meet the requirements for higher
classification in SAGA and which are not be transferred to the Negative List retain the
"under observation" classification.
24
SAGA 4.0
SAGA HOMEPAGE
SAGA DOCUMENT
Negative List
Mandatory
6
Recommended
(former Black List)
7
10
8
Right of Continuance List
(former Grey List)
3
5
Under observation
9
4
2
List of Suggestions
(former White List)
1
New standards
Figure 2-2: Lifecycles of SAGA standards
6
Following successful examination of the respective requirements in SAGA, standards
with "recommended" status are classified as "mandatory". Standards which after
examination still fail to meet the requirements for higher classification in SAGA and
which are not be transferred to the Right of Continuance List retain the
"recommended" classification.
7
Following examination and the respective re-evaluation in SAGA, standards with
"mandatory" status are classified as "recommended". A standard which should no
longer be used in new projects can also be directly transferred to the Right of
Continuance List. Transitions 7 and 8 are then carried out in a single step. Standards
which, after examination, continue to meet the requirements for classification as
"mandatory" maintain their status.
8
If, after in-depth examination, standards with a "recommended" status should not be
used any longer in new projects, these standards are transferred to the Right of
Continuance List.
9
Obsolete standards in the Right of Continuance List which were kept sufficiently long in
the Right of Continuance and which should not be maintained any longer are
transferred to the Negative List.
10 Standards with "under observation" status which no longer have any chance of ever
being transferred into a higher classification are directly transferred to the Negative
List.
The standards which are examined within the scope of preparing a new SAGA version can
not only move one step along the lifecycle previously presented, they can also retain their
status or pass through several steps in one go.
SAGA 4.0
2.3.4
25
Non-classified standards
Standards or architectures not listed in SAGA:
a. are not specific for eGovernment or eCommerce applications,
b. refer to a detail level other than that of the standards dealt with here in SAGA,
c. are included in or referenced by the aforementioned standards,
d. are too new or too controversial and are hence unlikely to become a standard in the
near future,
e. are not desired because they are in conflict with standards or architectures already
introduced or because they restrict interoperability.
2.4
SAGA conformance
2.4.1
Definition of conformance
The SAGA conformance of an eGovernment application54 is evaluated on the basis of the
models, procedures and standards described in SAGA:
a. Consideration of standardized process models
b. Consideration of standardized data models
c. Compliance with the standards and architectures described in SAGA
d. Use of existing one-for-all offers (OFA offers)55
In order to be able to make a comprehensive statement concerning the SAGA conformance
of an eGovernment application – especially in conjunction with the implementation of
complex, specialized processes – an application should first be broken down into individual
units56 before evaluating its conformance. Software units developed internally are
distinguished here from units (products) developed externally. In order to evaluate the
SAGA conformance of products, importance is primarily attached to communication
interfaces, data interchange formats and security. In the case of in-house developments,
the technologies for creating models and implementing the application are additionally
relevant as is the use of OFA offers.
The SAGA homepage provides a blank declaration of conformance and an example of a
completed declaration of conformance with checklists for software units and external
units57. The checklists feature topical areas which are relevant for in-house developments or
for products, respectively.
54 The term "eGovernment application" is used as a general term for any IT system which
provides eGovernment services of the Federal Government. With regard to the definition of
the term "eGovernment service", please refer to section 4.1.2 "The term "service" in
eGovernment" on page 35.
55 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76.
56 According to the XT process model, a unit is the system element on the very top of a
hierarchical structure; refer to http://www.v-modell-xt.de/
57 Refer to http://www.kbst.bund.de/saga-konformitaet
26
SAGA 4.0
eGovernment application
SW unit 1
(In-house
development)
External unit 1
(product)
...
Unit n
(...)
Check-list for SW
units developed
in-house
Check-list for
external units
(products)
...
Check-list for
...
Figure 2-3: Layout of the SAGA declaration of conformity and checklists
Which specific standards from the relevant topical areas have to be used to ensure SAGA
conformance varies depending on the area of application and the functional scope of the
application. For instance, definitions for creating information services for mobile phones
and/or PDAs are only relevant for SAGA conformance if these terminal devices are to be
used by the eGovernment application. SAGA conformance is hence achieved by applying
the particular subset of all SAGA standards which is relevant for the specific eGovernment
application.
2.4.2
SAGA conformance in invitations to tender
In order to avoid neglecting the customer's concrete requirements when it comes to SAGA
conformance and in order to avoid having to exclusively rely on statements by the supplier,
the customer should include a section on "SAGA conformance" and SAGA-relevant criteria
in its contracting documents.
A general demand for SAGA conformance is not enough in order to achieve the goals of
SAGA. Due to the complexity of the document, a general demand leaves too much room for
interpretation and misunderstanding. This makes it difficult for the supplier to fulfil the
requirements and for the customer to check that requirements are fulfilled.
This is why no general demand for SAGA conformance may be made.
Instead, the declaration-of-conformance process described below should be applied by the
customer and the supplier, refer to Fig. 2-4. This process limits the room for interpretation
and reduces misunderstandings. The concrete demands can be checked and thus create a
sound basis for the contract between the customer and the supplier. Specifying the
concrete details of demands also prevents offers from becoming unnecessarily expensive.
SAGA 4.0
27
SUPPLIER
CUSTOMER
Project started
1
Create contracting
documents
Send documents
with criteria related to SAGA
Send offer
3
Evaluate offer
considering supplier replies
concerning SAGA criteria
Write offer
including replies concerning
customer criteria related to SAGA
Award contract
Implement job
Hand over application
5
2
Perform acceptance
and subsequently complete SAGA
conformance declaration
4
and check
SAGA conformance
Project completed
Figure 2-4: Declaration-of-conformance process
The process essentially comprises five steps which are briefly described below.
Step 1: Including aspects of SAGA conformance aspects in the contract documents of an
invitation to tender
The customer puts together a series of exclusion and evaluation criteria which cover all the
relevant aspects of the desired application. The criteria group example which can be
downloaded from the SAGA homepage can serve as a template58. This criteria group
example contains possible criteria which can result from the application of SAGA. The
customer must select or supplement the criteria which are relevant for the project. The
criteria group example contains explanatory information which makes selection easier.
The customer must also decide whether criteria are defined as exclusion criteria or as
evaluation criteria. Exclusion criteria should be used very moderately because they reduce
the number of bids. Alternatively, high-weighted evaluation criteria should be taken into
consideration.
Step 2: Supplier response to the SAGA conformance criteria group within the scope of offer
preparation
The supplier responds to the "SAGA conformance" criteria group within the scope of his
offer preparation. He can base his offer on a completed criteria group example which can
also be downloaded from the SAGA homepage59. This criteria group is filled in, it serves as
28
SAGA 4.0
an example and contains explanatory comments which are helpful when filling in a
concrete criteria group.
Step 3: Supplier examination of the details concerning SAGA conformance, evaluation of the
respective criteria within the scope of offer evaluation
The customer checks the criteria groups completed for the offers received. Offers which do
not fulfil the customer's requirements for the "SAGA conformance" criteria group, i.e.
which cannot warrant "SAGA conformance", are evaluated accordingly.
Step 4: Supplier completion of the declaration of conformance for the completed application
If the supplier has implemented the eGovernment application, he declares the SAGA
conformance of the application in writing. To do so, he completes the declaration of
conformance for the application and attaches the checklists for the individual units of the
application. Deviations from the commitments made in the completed "SAGA
conformance" criteria group should be discussed with the customer at an early point in
time and the reasons for such deviations must be stated in the declaration of conformance.
The supplier can be supported by the sample declaration of conformance that can be
downloaded from the SAGA homepage60. Blank templates of a declaration of conformance
are also available on this homepage.
Step 5: Examining SAGA conformance on the basis of the offer and the declaration of
conformance by the supplier within the scope of acceptance
During acceptance, the customer can evaluate SAGA conformance on the basis of the "SAGA
conformance" criteria group completed by the supplier in the offer and the declaration of
conformance issued after implementation. This evaluation is as easy as possible thanks to
the specific details of the offer. If the application deviates from the commitments made in
the offer, this is deemed to be a defect which must be considered during acceptance.
2.4.3 SAGA conformance despite low classification
A SAGA-conformant application must not necessarily have been implemented solely with
technologies which were given a "mandatory" classification in SAGA. For various reasons,
the use of standards with a lower classification (or even without a classification in SAGA) is
possible without violating SAGA conformance61.
A lack of alternatives
The use of recommended standards is SAGA conformant if no mandatory alternatives exist.
Standards "under observation" can also be used and are SAGA conformant if no mandatory
or recommended standards are listed in SAGA for the respective application purpose.
61 Refer also to the definitions for classification and lists on the web in section 2.3 on page 20
SAGA 4.0
29
Special functions and application areas
If, for an area of application, SAGA not only contains higher classified standards
("mandatory" or "recommended") but also lists standards with a lower classification
("recommended" or "under observation"), the user must refer to the description of the
standards in order to find out the circumstances under which the lower classified standards
can be given preference. The reasons for this are, first and foremost, when extended
functionality62 is required, or special areas of application63. The use of standards "under
observation" should be particularly well considered because no investment security has
been established for these standards and because it is not warranted that they will remain
in effect. With the next version of SAGA, such standards can already be featured on the
Negative List (former Black List).
Parallel offers
If SAGA-conformant standards are used as depicted above, additional standards and/or
formats can be used which are not listed in SAGA or which have a lower classification in
SAGA. If, for example, spreadsheet data64 is made available in CSV format, the same data can
be additionally made available in other formats, such as Microsoft Excel, without violating
SAGA conformance.
Use of external units (products)
In the case of external units (in contrast to software units developed in-house), the focus is
placed on communication interfaces, data interchange formats and security. Technologies
for process modelling, data modelling, application architecture and the use of OFA offers65
do not form part of the checklists for the SAGA declaration of conformance. In the case of
certain units, customers should check whether the corresponding technologies should be
specified in order to make use, for instance, of existing infrastructures for operating the
unit and to achieve synergies with other eGovernment applications.
Technologies beyond the focus of SAGA
Of course, topics for which SAGA does not make or has not yet made any statements have no
effect on the evaluation of the SAGA conformance of an eGovernment application.
2.4.4 Responsibility for conformance
The public agency responsible for an eGovernment application is also responsible for
ensuring conformance with SAGA. The public agencies are also responsible for examining
ways to migrate special applications.
The federal ministries lay down rules for responsibility within their areas of competence.
62 Refer, for instance, to the descriptions for the different PDF versions in section 8.6.7.1 on
page 109
63 Refer, for instance, to the descriptions of Unicode coding in section 8.6.2 "Character sets" on
page 106
64 Refer to section 8.6.7.4 "Formats for spreadsheets for further processing" on page 112
30
SAGA 4.0
Due to the complexity of SAGA, the process of securing SAGA conformance is also complex.
This is why efforts are being made to provide even better support for users in future.
Information on the latest developments in this field can be found on the SAGA homepage66
of the Federal Ministry of the Interior.
2.4.5 Migration for conformance
Transition phase
SAGA is undergoing continuous development and regular updating so that it can be
adapted to meet new requirements. This is why individual eGovernment applications,
which are orientated towards an older SAGA version67 , may temporarily not comply with
the current SAGA version.
Migration plans should be developed for non-conformant applications if the result of the
cost-to-benefit analysis is positive. This may only be the case where major enhancements of
the application are concerned.
Measures to achieve conformance
The following measures are designed to support conformance with SAGA:
a. SAGA is included in project planning processes at an early stage.
b. Conformance with SAGA is specified and checked when projects are approved.
c. Conformance with SAGA can be a mandatory criterion for projects subsidized by public
administrations.
d. SAGA conformance is specified as a mandatory criterion for government contracts.
2.4.6 Non-conformance
eGovernment applications which are, as a whole or in part, non-conformant with SAGA are
subject to the following restrictions:
a. The use of one-for-all offers (OFA offers)68 can be restricted.
b. Advisory and consultancy services by competence centres are limited or even
impossible.
c. Interfaces with such systems may under certain circumstances not be supported.
d. Generally speaking, no subsidies are available from public administrations.
67 Old SAGA versions are available from the SAGA archive at: http://www.kbst.bund.de/saga
68 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76.
SAGA 4.0
3
3.1
31
Architecture model for
eGovernment applications
Overview
With the architecture model, SAGA aims at the following:
a. In an effort to facilitate communications, a common understanding of up-to-date IT
architectures, IT technologies and eGovernment structures is to be achieved.
b. IT technologies available for eGovernment applications are to be identified, compared,
evaluated with regard to their relevance, and given a uniform and consistent structure
using this model.
c. The aim is to provide uniform standards that can be used when it comes to
implementing eGovernment projects.
The Reference Model for Open Distributed Processing (RM-ODP69), which was standardized
as ISO/IEC 10746-3:1996, is the approach of choice for describing complex, distributed
eGovernment applications. The discussion on the application is broken down into different
viewpoints in order to reduce the complexity of the overall architecture and this in turn
makes it easier to understand and master an application. The object-orientated paradigm70
is the basis for the RM-ODP. Object orientation promotes clear-cut structures, re-usability
and updating capability of both the models created and the system.
The RM-ODP model defines five viewpoints of a system refer to Fig. 3-1:
a. The enterprise viewpoint specifies the purpose, use area and rules of an application.
b. The information viewpoint describes the structure and semantics of the data to be
processed, i.e. the data model.
c. The computational viewpoint represents the breaking down of an application into
functional elements and their interaction interfaces.
d. The engineering viewpoint represents the distribution of the individual elements of the
system to physical resources and their connections.
e. The technology viewpoint describes the technologies used to implement the system.
The five viewpoints can be used both to describe existing systems and to model new systems
and applications. SAGA suggests, but does not dictate, the use of RM-ODP to describe
69 Reference Model of Open Distributed Processing, refer to [ISO 1996]
70 Refer to [KBSt 2007], section 3.3.1
32
SAGA 4.0
Enterprise
Viewpoint
Purpose, use area
and rules
Information
Viewpoint
Computational
Viewpoint
Data structure
and semantics
eGovernment
Hardware and
infrastructure
Engineering
Viewpoint
System elements
and interfaces
Standards and
technologies
Technology
Viewpoint
Figure 3-1: Viewpoints according to RM-ODP
Furthermore, the SAGA document itself is structured according to the RM-ODP model. The
result are chapters which can each be assigned to a viewpoint; refer to section 1.8 "Structure
of the document" on page 18.
3.2
Enterprise viewpoint
The enterprise viewpoint for eGovernment applications includes two fundamental
elements: the organizational structure of eGovernment in general as well as the
organizational models of the application. This is where the overall environment for the
system and its purpose are described. Furthermore, the requirements for the system,
relevant constraints, executable actions and data processing policies are defined from the
organization's or enterprise's point of view. This exercise includes a definition of the
procedures, their rules, as well as the actors and their roles in the process.
The efficiency of information technology depends heavily on an integrated view. This
means that instead of focusing on information technology, the technical application is
primarily regarded and described as a process.
Services can and should be described in the form of technical process models. This means
looking at all the work steps from start to finish, i.e. from the inquiry by the "customer"
SAGA 4.0
33
(citizen, business, other public agency, etc.) to the rendering of the service. On their first
stage of development, these process models should be left at a relatively abstract level.
New proposals for process definitions should always be checked with a view to
a. Re-usability
b. Simplicity
c. The possibility to be described by existing process definitions.
The KBSt website provides a guideline for process and data modelling71 and supports those
in charge during process modelling. Support is also available from the "Workflow
Management, Processes and Organization" (WMPO CC) competence centre72 at the Federal
Office for Information Technology (BIT).
Chapter 4 "Enterprise viewpoint: Fundamentals of eGovernment" on page 35 describes the
enterprise viewpoint of German eGovernment as a model. In section 8.2 "Process models"
on page 95, SAGA provides the descriptive tools needed for the definition of the enterprise
viewpoint for concrete eGovernment applications.
3.3
Information viewpoint
This viewpoint determines the structure and semantics of the system's information.
Furthermore, the activities (status changes) which can be carried out with the information
objects are also defined along with the restrictions which apply to these activities.
A stringent process definition calls for the use of general data definitions for major data
identities (such as the application) and for the data to be exchanged between processes or
applications.
Data models should always be checked with a view to
a. Re-usability
b. Simplicity
c. The possibility to be described by existing data models
The KBSt website provides a guideline for process and data modelling73 and supports those
in charge during data modelling.
Chapter 5 "Information viewpoint: Standardization of data models" on page 55
corresponds to the information viewpoint of German eGovernment and should be
considered when creating own data models. Section 8.3 "Data models" on page 96 classifies
the technologies to be applied.
71 Refer to http://www.kbst.bund.de/modellierungsleitfaden
72 Refer to http://www.kbst.bund.de/, "E-Government" > "Vorgangsbearbeitung, Prozesse und
Organization"
73 Refer to http://www.kbst.bund.de/modellierungsleitfaden
34
3.4
SAGA 4.0
Computational viewpoint
This viewpoint breaks an application down into logic, functional elements which are
suitable for distribution. The result is objects with interfaces via which they offer their
functionality and/or use the functionalities of other objects.
Interaction takes place in the form of local and remote communication between the
elements. Secure interaction may be required here. The protection aims are described in
section 8.1.2.1 "Protection aims" on page 92.
The applications are also broken down into layers in which each of the individual elements
can be found.
Chapter 6 "Computational viewpoint: Reference software architecture" on page 65
provides a description of a general computational viewpoint of eGovernment applications
which can be used as a basis for creating this viewpoint for a concrete online service.
Furthermore, the chapter also describes the architectures of different cases of eGovernment
applications, such as systems and services. In chapter 8 "Technology viewpoint: Standards
for IT architecture and data security" on page 91, SAGA defines standards and technologies
for implementing the computational viewpoint and for creating secure interaction
between system elements.
3.5
Engineering viewpoint
The engineering viewpoint describes the system support needed to permit the distribution
of objects from the computational viewpoint. This includes system elements for executing
objects, such as computer hardware and communication infrastructures, as well as all kinds
of software platforms for distributed systems.
Chapter 7 "Engineering viewpoint: IT service management and reference infrastructure"
on page 79 gives a general description of the engineering viewpoint for eGovernment
applications of federal agencies. The corresponding viewpoint of a concrete online service
can be derived from this. Chapter 8 "Technology viewpoint: Standards for IT architecture
and data security" on page 91 presents several technologies to be adopted in order to
support network security.
3.6
Technology viewpoint
This viewpoint describes the concrete technologies selected for implementing the system.
In chapter 8 on page 91, SAGA describes the classified standards, technologies and methods
for the IT architecture and data security.
SAGA 4.0
4
35
Enterprise viewpoint:
Fundamentals of eGovernment
In line with the definition of the enterprise viewpoint in chapter 3 "Architecture model for
eGovernment applications", the fundamentals of eGovernment in Germany will be
described in the following as the overall environment for the standardized introduction of
Besides this general approach, the process level in eGovernment will also be addressed in
more detail. The process models are the starting point for deriving inter-agency modules
which are to be integrated into eGovernment applications.
4.1
Definitions of eGovernment in Germany
4.1.1
The term "eGovernment"
eGovernment (electronic Government) is understood to be the use of electronic
information and communication technologies in order to involve customers of
administrations in the activities of government and the public administration74. The aim is
to offer customers of administration services, i.e. citizens, businesses and the
administration itself, electronic access to administration services and information. The
possibilities offered by these technologies are very diverse. They range from the
modernization of administrative processes using electronic workflow management to the
provision of administrative information using public agency portals on the Internet and to
complex transactions and interactive electronic web services for citizens.
Aspects of eDemocracy are not explicitly addressed in this context because the government
is assumed to pursue different approaches towards its roles in relation to citizens and
business. As far as eGovernment is concerned, citizens and business are the clients of
administrations and governments. eDemocracy is based on the concept of the citizen as the
sovereign, representing the basis for the government to exert its power.
4.1.2
The term "service" in eGovernment
Within the scope of eGovernment, the term "service" is understood to be the execution or
result of an activity by a public administration which serves the citizen, business or another
public agency75. A service includes processes, obligations and burdens, such as the
recognition as a conscientious objector, applications for unemployment benefits, or the
granting of an import permit.
74 Refer to BSI: "eGovernment Glossary", version dated 4 January 2006, section 1.1, page 3;
http://www.bsi.bund.de/fachthem/egov/download/6_EGloss.pdf
75 Refer to BSI: "eGovernment Glossary", version dated 4 January 2006, section 1.2, page 4;
http://www.bsi.bund.de/fachthem/egov/download/6_EGloss.pdf
36
4.2
SAGA 4.0
The philosophy underlying
eGovernment
eGovernment opens up new ways for reform and innovation in the pubic administration
using electronic services and processes. This concerns internal relationships within
administrations on the one hand as well as external relations between administrations,
citizens and business on the other76.
4.2.1
Orientation towards the needs of citizens
The Internet and networked computer systems are shaping the future. The growing
penetration of the Internet, especially in private households, is also leading to a growing
demand for electronic services by government. eGovernment is the response to this
demand.
For citizens, contact with administrations sometimes involves long distances and waiting
time. Compared to this, Internet-based communication and transactions can help save
considerable amounts of both time and money. This means that in future many citizens will
frequently be able to handle their administration matters from the comfort of their own
homes. Internet portals simplify access to public information and services.
In order to tailor the service offered by administrations to demand, citizens must remain
free to choose which form of access to the administration they wish to use. Access to the
public administration must continue to be possible, in person, via the Internet and e-mail.
These access channels must be integrated into administrations as early and as far as
possible and processed in a standardized manner so that administration work can be
shaped as efficiently as possible. Moreover, Internet barriers and restrictions posed by the
Internet must be reduced and/or avoided.
4.2.2
eGovernment as a location factor for business
Companies maintain regular contacts with the public administration in many different
fields, e.g. for certification, licensing and approval procedures, as well as procedures
related to the customs and excise and tax administration.
On a global scale, all leading industrialized nations introduced powerful eGovernment
services in recent years. eGovernment is today a location factor. The national and EU plans
for expanding eGovernment services in the years to come are hence fully orientated
towards boosting benefits for citizens and especially for companies, as well as reducing the
cost of administration services. In some federal states, the focus is being placed on the
demand-based expansion of eGovernment services and on increasing the number of users.
The beginning integration of administration and business processes along value chains
makes it possible to reduce bureaucracy costs in the interest of business and government,
e.g. in the field of statistics or the import and export of goods.
76 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter I, module
"Chefsache E-Government – Leitfaden für Behördenleiter" [eGovernment as an executive
task – a guide for heads of public administrations]
SAGA 4.0
37
The availability and quality of electronic administration services is hence a factor not to be
underestimated in the global competition to entice companies to relocate or set up
business. Boundary conditions must be attractive and barriers for companies must be kept
as low as possible.
4.3
Strategic goals
The philosophy addressed in the previous section forms the main objective for the strategic
goals of eGovernment for Europe and Germany. In order to reach these goals, the public
administration must be modernized. A general overview of the programmes, strategies and
measures pursued by the Federal Government here with a focus on human resources,
administration management, organization and eGovernment can be found at
http://www.verwaltung-innovativ.de/. The following section presents the Federal
Government's central programmes and strategies which, in the years to come, will pave the
way for the further development of eGovernment on Federal, federal-state and municipal
level in Germany.
4.3.1
eGovernment 2.0 – A Federal Government
programme
The top priority of the eGovernment 2.0 programme77, which was adopted by the Federal
Cabinet in September 2006, is to make the federal administration fit for a service-orientated
information society. The needs of users of eGovernment applications are to be focused on
more in the future – for instance, users are to be enabled to communicate with public
agencies without the fear of identity fraud or electronic annoyance78. Accordingly, the
federal administration's Internet offering is to be expanded by 2010, both in terms of quality
and quantity. The programme is being coordinated by the Federal Ministry of the Interior in
cooperation with the different federal ministries.
The goals listed are supported by measures in four fields of action:
a. Portfolio
Demand-orientated, quality and quantity-related expansion of the eGovernment
offering by the Federal Government (e.g. Arbeitsagentur-Online [online job agency]79)
b. Process chains
Media-consistent electronic process handling between business and the administration
using integrated process chains, as well as standards for interface and exchange
formats (e.g. secure foodstuff chain80)
77 Refer to http://www.kbst.bund.de/e-government/
78 National Plan for Information Infrastructure Protection (NPSI): Federal Ministry of the
Interior, 2005; http://www.bmi.bund.de/, navigation topics "Themen A-Z" [A-Z topics] >
"Informationsgesellschaft" [Information society] > "Sicherheit in der Informationstechnik"
[Security in information technology] > box: "Links zum Thema" [Links to the topic]
79 Refer to http://www.arbeitsagentur.de/
80 IT FoodTrace research project: http://www.itfoodtrace.de/
38
SAGA 4.0
c. Identification
Launch of electronic identity management using future functions and applications, e.g.
on the electronic ID card (ePA)81 as well as the development of eIdentity strategies
d. Communication
A secure communication infrastructure in the form of portals for citizens, businesses
and administrations (e.g. citizens' portals82)
4.3.2
Deutschland-Online - The joint eGovernment
strategy of the Federal Government, federal-state
governments and municipalities.
The aim of Deutschland-Online (DOL)83 is to create a fully integrated eGovernment
landscape in Germany, so that electronically captured data can be exchanged between the
administrations of the Federal Government, federal states and municipalities in a
consistent manner and across all levels. This strategy is based on the following principles:
a. One For All (OFA)
The individual participants from Federal Government, the federal states and
municipalities develop model solutions which are used by the other participants.
b. Responsibility of lead units
The main responsibility for a DOL project lies in the hands of the proposing public
agency which is also in charge of the creation of a tenable business model and its
implementation.
c. Transparency of standards – competition between products.
Transparent standards and process models are used to define a framework for which
various products can be selected, hence promoting interoperability between different
products.
In order to implement the strategic goals, the heads of federal and federal-state
government adopted the Deutschland-Online action plan in June 2006 with six prioritized
projects and extended this in June 2007 with the IT implementation of the EU services
directive84:
Infrastructure85
The Federal Government, federal states and municipalities currently have different
network infrastructures wich are not connected to each other and hence constitute island
solutions. This means that for a host of public agencies it is not always possible to exchange
data with other agencies in a reliable, simple and secure manner. The establishment of a
81 Refer to http://www.epass.de/
82 Refer to http://www.kbst.bund.de/e-government/, navigation item: "Bürgerportale"
[Citizens' portals]
83 Refer to http://www.deutschland-online.de/
84 Refer to http://www.deutschland-online.de/, navigation item "Strategie" [Strategy] >
download: "Aktionsplan Deutschland-Online vom 14.06.2007.pdf" [Deutschland Online
action plan dated 14 June 2007]
85 Refer to http://www.deutschland-online.de/, navigation item "Vorhaben" [Projects] >
"Priorisierte Vorhaben" [Prioritized projects] > "Infrastruktur" [Infrastructure]
SAGA 4.0
39
communication infrastructure for Germany's public administration is designed to create a
uniform network and hence achieve secure electronic communications between public
agencies on Federal, federal-state and municipal level.
Standardization
The purpose of the DOL "Standardisierung" [Standardization] project is to support and
coordinate the development and provision of technical standards for electronic data
interchange (XÖV standards), so that electronic administration processes can be
implemented in an efficient and uniform manner. For this purpose, the project for
supporting the XÖV projects offers public administrations coordinated and harmonized
measures, such as development methods, standardized data models, tools and technical
infrastructures, along with advisory services and PR work.86
IT implementation of the EU services directive87
The goal of the project is to simplify and accelerate electronic administration processes in
Germany within the scope of the EU services directive88. As of the end of 2009,
entrepreneurs in the European Union are to be able to launch and perform their service
activities via a uniform online contact, irrespective of their nationality or of the member
state in which they are currently located. By mid-2008, a model for the IT implementation
of the directive will be developed and tested as a milestone on the road towards this goal.
Within the scope of this model, the infrastructural requirements at national level are to be
defined, the IT support required for media-consistent process handling is to be described, a
suitable IT architecture developed and technologies proposed with a view to the interfaces
required.
Registration services89
The registration data of 82 million citizens in Germany is currently electronically captured,
registered and managed in a distributed manner at more than 5,000 registration offices
and used in approx. 114 million business transactions every year – for instance to provide
information. As of 1 September 2006, the Federal Government was given the sole legislative
competence of registration services as part of federalism reform. The aim is to create a
Federal Identity Register (BMR) in addition to the municipal register in order to simplify
registration procedures for citizens, to make use of the identity register more efficient and
less expensive for businesses and administration, to improve the quality and up-to-dateness
of the registration data and to make it possible to create nationwide, uniform online
services.
86 For more details, refer to section 5.3 "The Deutschland-Online "Standardization" project" on
page 59 and http://www.deutschland-online.de/, navigation items "Vorhaben" [Projects] >
"Priorisierte Vorhaben" [Prioritized projects] > "Standardisierung" [Standardization]
87 Refer to http://www.deutschland-online.de/, navigation item "Strategie" [Strategy] >
download: "Aktionsplan Deutschland-Online vom 14.06.2007.pdf" [Deutschland Online
action plan dated 14 June 2007]
88 Refer to section 4.5.4 "EU services directive – Creating a single EU market" on page 48
"Priorisierte Vorhaben" [Prioritized projects] > "Meldewesen" [Registration services]
40
SAGA 4.0
Motor vehicle registration services90
Citizens and the business sector can currently perform certain tasks in conjunction with the
registration, de-registration and re-registration of motor vehicles online (e.g.: entering
vehicle data to prepare for registration, reserving custom registration numbers). Citizens,
however, still have to carry out the actual procedure itself on site at the registration offices.
The aim of the project is to find an organizational, legal and technical solution for vehicle
registration which offers citizens and the business sector a consistent process via the
Internet without media inconsistencies.
Civil status registration services91
On 23 February 2007, the "Gesetz zur Reform des Personenstandsrechts (PStRG)" [Law
Reforming Civil Status Law] was ratified permitting, as of 1 January 2009, electronic
registers and making these, as of 1 January 2014, mandatory. The aim of the project is to
develop an electronic procedure for civil status registration services based on the Law and
to use this to implement pilot projects for civil status registration services in certain federal
states and also to enable citizens to obtain register information and apply for documents
online. Part of the project also involves automated communications between the civil status
register and other public agencies in response to requests for information. This exchange is
to support the "XPersonenstand" data format to be developed.
Other Deutschland-Online projects
In addition to the previously described projects, there are a number of other projects being
implemented within the scope of Deutschland-Online92:
a. Official statistics
b. BAföG (Federal Education Assistance Act)
c. Clearing houses
d. German Forum for Electronic Signatures and Chip Cards
e. Geodata
f.
Business models
g. Commercial register
h. Judicial register
i.
VEMAGS (Procedure management for bulk and heavy transports)
j.
Internet portals / Responsibility finder project
k. XAusländer [XForeigners]
"Priorisierte Vorhaben" [Prioritized projects] > "Kfz-Wesen" [Motor vehicle registration
services]
"Priorisierte Vorhaben" [Prioritized projects] > "Personenstandswesen" [Civil status
registration services]
"Weitere Vorhaben" [Other projects]
SAGA 4.0
l.
41
XSozial [XSocial]
4.4
Organizational requirements
The implementation of eGovernment in Germany is bound by organizational requirements
which must be taken into consideration. The most important of these requirements are
described in the following.
4.4.1
Cross-administration interaction
Federalism in Germany
When implementing eGovernment, federalist states like Germany must face the problems
of a de-centralized administration structure because the de-centralized administrative
units are largely independent of central government.
Whilst the Federal Government holds most of the legislative power, it is the federal states
and municipalities that are mainly responsible for implementation. The direct federal
administration performs national tasks. Only those functions specifically defined in the
Grundgesetz93 [German Basic Law] (articles 87-89) have an underlying administrative
structure of their own, such as the Foreign Service, the Federal Armed Forces, the Federal
Police or the Federal Revenue Administration. Besides these functions, there are other
national tasks which are typically performed by special administrative agencies without an
underlying administrative structure of their own (e.g. the Federal Criminal Police Office, the
Federal Statistics Office, the German Patent and Trade Mark Office).
The immediate federal administration consists of:
a. The supreme federal authorities, e.g. the federal ministries, the Office of the Federal
President and the Press and Information Office of the Federal Government
b. The superior federal authorities with central responsibility for a particular aspect for
the entire Federal Republic of Germany (for example, the German Federal Cartel Office)
c. The intermediate-level federal authorities with regional responsibility (e.g. the
different regional tax offices)
d. The lower-level federal authorities with locally restricted activities (for example, main
customs and excise offices)
Within the scope of certain federal-state tasks related to law enforcement, the Federal
Government commissions external administrative bodies as independent legal entities.
These legal entities, in their capacity as corporate bodies, institutions and foundations of
the indirect federal administration, are independently responsible for their fields of
competence throughout the territory the Federal Republic of Germany and report to a
ministry.
Comparable structures exist in the individual federal states. Furthermore, cities, districts
and municipalities constitute the third administrative level in their capacity as territorial
93 Basic Law of the Federal Republic of Germany [German Constitution] (GG):
http://www.gesetze-im-internet.de/bundesrecht/gg/
42
SAGA 4.0
communities with autonomous administrations which also perform their own tasks in
addition to federal and federal-state functions.
The users of eGovernment services usually do not differentiate between the federal,
federal-state and municipal levels of administration. Instead, companies and citizens tend
to expect standardized and consistent eGovernment services, refer to Fig. 4-1.
Fed.
Gov.
§
Fed.
States
G2G
Agency
§
Municipalities
§
G2G
Agency
Agency
G2G
G2G
§
§
G2G
Agency
Agency
G2C
G2B
€
Citizens
Business
Figure 4-1: eGovernment interaction in Germany
What is generally needed is cooperation, networking and coordination within and
between administrative levels. A first step taken at federal level was the implementation of
the Informationsverbund Berlin-Bonn (IVBB)94 [Information Network Berlin-Bonn] which is
an intranet for the supreme federal authorities. The upgrading of this network to form the
Informationsverbund der Bundesverwaltung (IVBV)95 [Federal Administration Information
Network] will connect all the federal authorities to a secure, closed network – this
constitutes an enormous challenge on both a technical and organizational level96.
With Deutschland-Online as the joint national eGovernment strategy of the Federal
Government, the federal states and municipalities, an expanded action plan was presented
in June 200797.
94 Refer to http://www.kbst.bund.de/ivbb
95 Refer to http://www.kbst.bund.de/ivbv
96 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter V, subchapter C, module: "Network platform for eGovernment"
97 Refer to section 4.3.2 "Deutschland-Online - The joint eGovernment strategy of the Federal
Government, federal-state governments and municipalities." on page 38
SAGA 4.0
43
Germany as a member of the European Union
As a member of the European Union (EU), the Federal Republic of Germany is increasingly
being required to implement cross-border eGovernment services like those demanded in
the EU services directive. The goal is to create a uniform, single market in the EU and to offer
all citizens and businesses the same opportunities and rights.
As shown in Fig. 4-298 , national services have to be offered more to citizens, business and
public agencies of other member states. Cooperation with the EU administration is also to
become more important in the future.
MEMBER STATE A
MEMBER STATE B
National eGovernment interaction
Cross-border eGovernment
interaction
G2C
Citizens
Citizens
G2C
€
€
G2B
Business
Business
G2B
§
§
G2G
G2G
Agency
Agency
G2G
§
Agency
§
EU
ADMINISTRATION
Agency
Figure 4-2: National and cross-border eGovernment interaction
Citizens and businesses using such cross-border eGovernment applications do not
differentiate between the different areas of responsibility of national administrations,
instead they expect a uniform, multilingual and consistent eGovernment offering between
the member states. This means that in future it must be possible, for instance, for a building
contractor in Italy wishing to relocate to Spain to be able to carry out the required
communications with public agencies electronically from Italy. The contractor only
communicates with one contact partner in this context. The necessary interaction between
the different administrations in the member states takes place in the background as a cross98 Pursuant to the "European Interoperability Framework for Pan-European eGovernment
Services" (EIF) v1.0, IDABC, 2004; http://ec.europa.eu/idabc/servlets/Doc?id=19528, page 12,
Fig. 3
44
SAGA 4.0
border eGovernment application without the contractor being aware of this or having to
contact the individual agencies.
In addition to the registration of companies, the following areas were identified for crossborder applications: tax returns, applications for unemployment benefits, motor vehicle
registrations. The EU services directive99 provides the corresponding framework for the
implementation of these applications.
4.4.2 Optimization of administrative processes
The successful introduction and implementation of eGovernment calls for the examination
of grown processes. Existing rules, processes and structures must be adapted and simplified
in a suitable manner taking technical and legal circumstances into consideration. The mere
electronic implementation of conventional procedures seldom leads to optimization.
Existing administrative processes are partly the result of historical developments and have
become complex over the course of time as a result of many changes. The following
measures are hence recommended before special applications are implemented
electronically.
a. Simplification of processes and procedures
b. Deregulation
c. Shortening of process chains
d. Reduction in the number of interfaces
e. Avoiding iteration
f.
Reduction in cycle and dead times100
First steps towards reducing red tape were designed to simplify processes and legal
regulations for administration services. This is why Deutschland-Online101 covers services
that concern several administration levels. The Federal Government's "Zukunftsorientierte
Verwaltung durch Innovationen"102 [Future-orientated administration through innovation]
programme triggers level-spanning processes which lead to an open dialogue on a joint
vision for a future-enabled, network-orientated administration in Germany.
4.4.3 Qualification of staff
The use and updating of standards, along with the development, operation and correct
handling of IT-supported systems, calls for the continuous exchange of information and
training. Many employees in the public sector are highly motivated when it comes to
supporting eGovernment. This important asset must be exploited and increased in the
interest of implementing eGovernment. This means that intensive training must be carried
out for employees. Moreover, the administration must be made more attractive for IT
experts.
99 Refer to section 4.5.4 "EU services directive – Creating a single EU market" on page 48
100 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter III, module
"Phase 3 – Analysis"
101 Refer to http://www.deutschland-online.de/
102 Refer to http://www.verwaltung-innovativ.de/
SAGA 4.0
45
4.4.4 Involvement of users
The use of eGovernment is strongly dependent on customer acceptance of the services
offered. Full utilization of the savings potential of eGovernment is contingent upon the
online services provided being accepted and used by potential users. Expectations among
citizens, companies and public agencies as the specific target groups need to be identified
on an ongoing basis. The service portfolio and the service rendering process must be
adapted to these expectations.
4.5
Legal frame of reference
In addition to the strategic goals and organizational frame of reference, legal guidelines
must also be considered. The most important of these will be described in the following
along with the legal adjustments in conjunction with the electronic signature, laws,
ordinances and assistance for data protection and barrier freedom as well as the EU services
directive. A detailed description of the legal adjustments implemented can be found in the
Federal Government's E-Government-Handbuch103 [eGovernment manual].
4.5.1
Electronic signatures
Electronic signatures allow users of eGovernment applications to have themselves
authenticated104. Sensible, practical and timely legal adjustments will make it possible for
eGovernment to shape administrative processes efficiently and without media
inconsistencies.
Legal adjustments
The legally binding nature of electronic communications is a crucial success factor for the
implementation of eGovernment. What is hence needed is a digital solution for a signature
with legally binding effect, i.e. the qualified electronic signature. Contrary to a simple or
advanced electronic signature, a qualified electronic signature offers the highest degree of
electronic replication of a handwritten signature. The legal adjustments required to enable
the use of electronic signatures and to place these on the same standing as a hand-written
signature have been completed in Germany. Besides amendments to the Signaturgesetz
[Act on Digital Signature] to comply with European requirements, the electronic signature
has also been integrated into the relevant blanket clauses in administrative and private
law105.
Dissemination of the electronic signature
The dissemination and acceptance of qualified electronic signatures has been slow up to
now due to the still prevailing disproportion between benefits and costs. For instance,
103 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter II, module:
"Legal frame of reference for eGovernment"
104 Refer to section 8.5.4 "Technologies for authentication" on page 104, section 8.10 "Electronic
signature" on page 133 and section 8.10 "Electronic signature" on page 133
105 For information concerning the legal basis for the electronic signature, please refer to
http://www.bsi.bund.de/esig/
46
SAGA 4.0
qualified electronic signatures are only used up to now in a few mass processes and
administration areas, for example, in invoicing.
The reasons for this are mostly related to security in the application of signatures and
signature cards, the lack of interoperability between different signature applications, as
well as the limited legal recognition in just a few individual states.
In order to bridge these security-related concerns, the Bundesnetzagentur (BNetzA)
[Federal Network Agency] has already examined and certified products for qualified
electronic signatures106. These products comply with the necessarily high security
requirements of the Signaturgesetz107 (SigG) [Act on Digital Signature] and the
Signaturverordnung108 (SigV) [Digital Signature Ordinance].
Furthermore, the costs involved in reorganizing internal administrative workflows,
installing systems (smartcards, software, card readers) and ongoing use (the need to have
the signature key regularly renewed) is a factor for administrations which, compared to the
benefits, is still relatively high and hence hinders faster dissemination.
When it comes to citizens, on the other hand, there is a need to inform about the use and
added value of electronic signatures. First practical applications show that smartcards are
particularly attractive for citizens if they can use them for both private-sector and public
services.
Federal Government initiatives and projects in the field of electronic signatures
The signature initiatives and projects of the federal administration are to be more closely
coordinated with each other in the future in order to promote dissemination and
acceptance, especially in conjunction with signature cards. The following cases are
example of projects by the federal administration dealing with the use of signatures and
signature cards:
a. The electronic health card109
The electronic health card covers the electronic prescription, the European healthinsurance card, data for emergencies, documentation of medication as well as the
electronic patient file. Furthermore, an electronic medical profession ID card is being
developed which a doctor can use to generate a qualified electronic signature to
replace the current, independent signature, for instance, to "sign" an electronic
prescription for a patient. Field tests with the electronic health card began in December
2006.
b. The electronic ID card (ePA)110
The electronic signature function is also to be optionally integrated into the electronic
ID card. "Optionally" means that the electronic ID card is prepared to hold a qualified
signature certificate, but the certificate itself must then be loaded into the memory chip
106 Federal Network Agency (BNetzA):
http://www.bundesnetzagentur.de/enid/Elektronische_Signatur/Produkte_pi.html
107 Act on the boundary conditions for digital signatures (SigG): http://www.gesetze-iminternet.de/sigg_2001/
108 Digital Signature Ordinance (SigV): http://bundesrecht.juris.de/sigv_2001/
109 Refer to http://www.die-gesundheitskarte.de/
SAGA 4.0
47
by the holder of the ID card. This freedom of choice means that the card can be used
according to specific needs. The integration of biometric information and an
authentication function round off the future electronic ID card, making it reliable proof
of identity and a universal, future-enable and secure key for eGovernment and
eBusiness.
c. The electronic tax return (ELSTER)111
Within the scope of the electronic tax return, citizens and businesses can, for instance,
complete and submit online VAT returns, wage tax returns or wage tax certificates. It is
also possible to view tax accounts; this requires a signature card which is supported by
the system. An overview of such signature cards is provided on the website112.
4.5.2 Data protection
eGovernment offers a host of options and rationalization potential in the IT sector. Ideally,
data from the most varied contexts is gathered once only by a central function and could be
subsequently available for any de-centralised purpose and use.
However, when electronic data is interchanged within and between public agencies, data
protection requirements must be considered and implemented by way of suitable technical
and organizational measures. Personal data, in particular, may not be gathered, processed
or disclosed for any purpose other than the use explicitly contemplated by law.
The Federal Government's E-Government-Handbuch [eGovernment manual] includes a
separate module113 with comprehensive information concerning the issue of dataprotection-compliant eGovernment. Under the title "Technological Data Protection", the
Federal Commissioner for Data Protection and Freedom of Information provides
orientation aids for certain application cases114, such as the use of document management
systems or cryptographic methods.
4.5.3 Barrier-freedom
More than eight million disabled people, 6.6 million of whom are severely disabled, live in
Germany. People with impaired vision and physical handicaps are especially dependent on
technical aids as a precondition for using the Internet, such as large screens or a
magnifying-glass function, Braille line, voice output, etc. In order to optimally enable these
devices for eGovernment applications, a host of rules and requirements must be considered
during programming, designing and editing.
On 1 May 2002, the new Behindertengleichstellungsgesetz115 (BGG) [Law on Equal
Opportunities for the Disabled] came into effect. The aim of this Law is to overcome
111 Refer to http://www.elsteronline.de/
112 Refer to https://www.elsteronline.de/eportal/Sicherheit.tax#sigkarte
"Data-protection-compliant eGovernment"
114 Refer to http://www.bfdi.bund.de/, "Startseite Datenschutz" ["Home" page - Date
protection] > "Themen" [Topics] > "Technologischer Datenschutz" [Technological Data
Protection]
115 Law on Equal Opportunities for the Disabled (BGG): http://www.gesetze-iminternet.de/bundesrecht/bgg/
48
SAGA 4.0
disadvantages for disabled people, to ensure their discrimination-free participation in
social life and to enable them to live an autonomous independent life.
This is also applicable to the use of the Internet. The most important criteria and references
are to be found in the Ordinance on the Creation of Barrier-free Information Technology
pursuant to section 11 of the BGG (Barrierefreie Informationstechnik-Verordnung – BITV116)
which came into force on 24 July 2002. This ordinance specifies the Web Content
Accessibility Guidelines117 1.0 (WCAG 1) from 1999 as the technical standard. The BITV is
binding upon public agencies of the federal administration118 since 1 January 2006 and
applies to:
a. website and Internet offerings,
b. intranet sites and offerings which are available to the general public,
c. IT-based graphic user interfaces which are available to the general public.
4.5.4 EU services directive – Creating a single EU market
The EU services directive119 was adopted on 12 December 2006 by the European Parliament
and the European Council. The aim of the directive is to reduce red tape in the European
Union (EU), to promote the cross-border provision of services120 and hence the resultant
implementation of a uniform, single EU market. This directive must be implemented by the
end of 2009. Within the scope of electronic procedures, it covers, for instance, the demands
for:
a. Points of single contact
"Member states shall ensure that it is possible for providers to complete the following
procedures and formalities through points of single contact:
a) all procedures and formalities needed for access to his service activities, in particular,
all declarations, notifications or applications necessary for authorization from the
competent authorities, including applications for inclusion in a register, roll or a
database, or for registration with a professional body or association;
b) any applications for authorization needed to exercise his service activities." (Article 6
(1))
b. Ensuring access to and exercising of services
"Member states shall ensure that all procedures and formalities relating to access to a
service activity and to the exercise thereof may be easily completed, at a distance and by
116 Ordinance on the creation of barrier-Free information technology pursuant to the Law on
Equal Opportunities for the Disabled (BITV): http://www.gesetze-im-internet.de/bitv/
117 Refer to http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/
"Barrier-free eGovernment"
119 Directive 2006/123/EC of the European Parliament and of the Council of 12 December 2006
on services in the internal market: http://ec.europa.eu/internal_market/services/servicesdir/index_de.htm
120 Contrary to the customary use of the term "service" in conjunction with eGovernment (refer
to section 4.1.2 "The term "service" in eGovernment" on page 35), the following definition of
a service is used in conjunction with the EU services directive: "[...] any self-employed
economic activity, normally provided for remuneration" (article 4, para. 1)
SAGA 4.0
49
electronic means, through the relevant point of single contact and with the relevant
competent authorities." (Article 8(1))
c. Taking common standards into account
"The Commission shall, in accordance with the procedure referred to in Article 40(2),
adopt detailed rules for the implementation of paragraph 1 of this Article with a view to
facilitating the interoperability of information systems and use of procedures by
electronic means between Member States, taking into account common standards
developed at Community level." (Article 8 (3))
4.6 Processes in eGovernment
4.6.1
Levels of interaction
eGovernment services can be generally broken down according to interaction levels, i.e.
information, communication and transaction121.
Information covers the provision of information to people, businesses and other members
of society. Users on this level merely act as recipients of information. This area is the most
developed level, and almost all public institutions are present on the Internet with an
website.
Many of these information systems are supplemented by communication solutions with
interactive and participation services which enable the exchange of news, messages and
information. These services range from simpler solutions, such as e-mail or web-based
discussion forums, right through to more complex applications, such as video conference
systems for telecooperation. In this respect too, the development status of German
administrations can be described as being well advanced.
Transaction applications feature the highest level of interaction. This area covers the
actual provision of services in the public administration. These applications include, for
instance, the electronic receipt and processing of applications or orders as well as the
provision of forms which are filled in on the computer and directly sent to the proper
recipient. Electronic payment or tendering systems also belong to this category.
Compared to other levels of interaction, transaction services have been implemented to a
lesser extent up to now. Public Key Infrastructures (PKIs) are an important precondition
when it comes to ensuring the authenticity and confidentiality of the data exchanged
between the different parties. The electronic exchange of documents with legally binding
effect still involves technical and organizational challenges for public administrations and
a satisfactory solution has yet to be found here. Another adverse factor is the currently
sparse dissemination of the electronic signature in all parts of society.
4.6.2 Relationships in interaction
Besides the classification in terms of interaction levels, the various partners involved in
eGovernment can also be differentiated122, refer to Fig. 4-1 on page 42:
121 Refer to [v. Lucke et al. 2000], page 3
122 Refer to [v. Lucke et al. 2000], page 3
50
SAGA 4.0
a. Government to citizen (G2C)
Electronic interaction between citizens and the administration – this area also includes
non-profit organizations
b. Government to business (G2B)
Electronic business relations between the administration and the business sector
c. Government to government (G2G)
Electronic relations between different public agencies and public administration
institutions
Administration customers are hence citizens, business and other administrations. The focus
in this case is on the G2C and G2B interaction relations. Relations between public agencies
(G2G) are handled within the framework of the relevant transaction services between
administrations and citizens and/or businesses. Communications within a public agency
(government-to-employee, G2E) are not explicitly addressed in this context.
4.6.3 Transactions in eGovernment
As mentioned earlier in section 4.6.1, public administration services not only cover pure
services, but also rights and obligations. A functional classification of administrations is
necessary as a precondition for standardizing the different types of administrative activity –
and hence the possible transactions. Generally valid types of transactional services can be
identified on this basis.
Transactional service types
The German administration can be divided into service and intervention functions based
on responsibilities and legal forms. Different service types can be identified and classified as
service-type and intervention-type services on the basis of the different categories of
functional administrative branches.
Services mean that citizens or a business enterprise demand from the administration a
service or benefit, i.e. the citizen or business initiates the process. Services include:
a. Applications for government money
b. Granting of subsidies
c. Subsidy and promotion measures
d. Approval procedures
Intervention is a case where the administration enters into the citizen's legal sphere,
encroaching upon the citizen's freedom or property and/or imposing obligations upon the
citizen. In this case, certain measures are initiated by the administration. Cases of
intervention are:
a. Administrative fines
b. Criminal prosecution procedures
c. Legal proceedings
SAGA 4.0
51
d. Collection of taxes
e. Collection of customs duties
f.
Registration obligations
Public procurement represents another service type where the government acts as the
customer for businesses. Contracts for goods and services are subject to defined
administrative procedures.
Process-related structure of transaction services
The individual transaction types can be broken down further into individual sub-steps. The
sub-steps consist of one or more actions in which different actors are involved. Examples of
sub-steps, actions and roles related to the service area will be discussed in the following.
This methodological approach can then be used as a basis for developing similar process
models for any other transaction type.
The sub-steps, which are correlated with each other and explained in more detail in Fig. 4-3
and in Table 4-1, are now defined for the services area. Every sub-step involves different
actions and roles which are attributed to different actors. The "application" sub-step, for
example, includes the actions of submitting, transmitting and receiving the application.
1
Information
2
Application
3
Processing
5
Decision
Comment and
opinion
6
Collection of
administrative
fees
4
Payment or
disbursement of
funds
7
Control of fund
application
8
Archiving
9
Figure 4-3: Sub-steps of transaction services
10
Other procedures
(e.g. appeal)
52
SAGA 4.0
The applicant's role is typically performed by a citizen or company. At the public agency,
the post office – ideally a virtual one – receives the application and passes it on to the officer
in charge.
In analogy to this procedure, the other sub-steps include further actions and roles which
are summarized in the table below.
Sub-steps
1
2
3
Information
Application
Processing
Actions
Roles
Provision of information
Editorial team
Information request
Interested party
Submission of application
Applicant
Transmission of application
(Virtual) post office
Receipt of application
Officer
Examination of the case
Officer, superior, other officers
Request for information
Officer, superior, (virtual) post
office, other officers
Applicant, (virtual) post office
4
Comment and
opinion
Information evaluation
5
Decision
Writing the decision
Officer, superior
Service of the decision
Applicant, (virtual) post office
6
Collection of
Collection of fees
administrative
fees
Payor, (virtual) cashier's office
7
Payment or
disbursement
of funds
Payee, (virtual) cashier's office
8
Control of fund Examination of the case
application
Request for information
9
Archiving
10 Reference to
other
procedures
Payment
Officer, superior, (virtual) post
office, other officers
Payee, (virtual) post office
Archiving
Officer, records management unit
Data transmission
Applicant, officer, other public
agencies and officers
Table 4-1: Sub-steps, actions and roles of transaction services
Not every service type defined in the section on "Transactional service types" on page 50
must necessarily include all the sub-steps. Depending on the particular process, sub-steps
can be carried out repeatedly during the life of a case.
4.7
Modules for the implementation of
The analysis of service types presented in section 4.6 "Processes in eGovernment" on page
49 and the related identification of sub-steps, actions and rules can be used as a basis for
SAGA 4.0
53
identifying functional modules which – given the required configuration possibilities – can
be used to implement different procedures using information technology. The potential
applications of these modules are dependent upon the quality of the process analysis and
the chosen software architecture123.
The following types of modules can be defined in conjunction with the above-described
procedure.
a. User interface
The analysis of the different roles leads to a need to develop certain modules which
provide functions for accessing the eGovernment application. This includes a
standardized, easily recognized user interface for user and role management functions
as well as functions for authenticating users in the system.
b. Process modules
The actions identified are standardized, if necessary, and implemented as a service or
system and defined with priorities depending, for instance, on the potential frequency
of use in the implementation of the business logic.
c. Infrastructure modules
Other modules standardize and implement communication with the other
components of electronic procedures.
The German federal administration's one-for-all services (OFA services) were largely created
within the scope of the BundOnline Initiative124 and are described in more detail on the KBSt
website125 as examples of such modules. The creation of specialist applications on the basis
of reusable services and systems is outlined in chapter 6 "Computational viewpoint:
Reference software architecture" on page 65.
123 Refer to chapter 6 "Computational viewpoint: Reference software architecture" on page 65
124 Refer to http://www.bundonline2005.de/
125 Refer to http://www.kbst.bund.de/efa
SAGA 4.0
5
55
Information viewpoint:
Standardization of data models
This chapter describes as the information viewpoint according to RM-ODP126 how
interoperability between applications is established and/or improved by standardizing
data models using suitable modelling methods.
5.1
Levels of interoperability
One important SAGA goal is to secure the interoperability of eGovernment applications,
refer to section 1.3 "Aims"on page 12. Defining the technology viewpoint on XML as the
standard for exchanging data127 merely provides a technical basis for this. Although XML
does offer the required technical basis, but just like a series of correct words in a certain
language do not necessarily make a sensible sentence, XML alone is not sufficient when it
comes to warranting interoperability between applications. In order to be able to ensure
that data can be sensibly interchanged between systems and further processed, it is vital
that interoperability be secured, not just on a technical level, but also on an organizational
and semantic level.
Organizational interoperability
Organizational interoperability primarily determines when and why certain data is
exchanged. This means that within the scope of organizational interoperability, processes
which result in the interchange of data are coordinated with a view to legal parameters (e.g.
legislation and regulations).
Technical interoperability
Technical interoperability on the other hand refers to the mere possibility to exchange
information. Technical interoperability includes the definition of transmission routes and
protocols (e.g. SOAP, HTTP, FTP, IP, SMTP). The respective standards are referenced in the
technology viewpoint, for instance in section 8.7 "Communication" on page 121. A common
language for data description is the required technical precondition for interoperability.
Section 8.6.6 on page 109 identifies XML as the mandatory standard for exchanging data.
Semantic interoperability
Semantic interoperability is given when two systems exchange data in such a manner that
the data is interpreted in the same way by both communication partners and
misunderstandings are ruled out. This applies not just to the form but also and especially to
the content of the data transmitted.
126 Refer to chapter 3, "Architecture model for eGovernment applications”, section 3.4
"Computational viewpoint” on page 34
127 Refer to section 8.6.6 "Interchange formats for data ” on page 109
56
SAGA 4.0
Semantic interoperability is achieved by defining a uniform presentation form and
semantics for the elements of the XML files exchanged. This definition can be achieved, for
instance, by specifying concrete data models in the form of XML schemas (XSD) or by a
Regular Language Description for XML New Generation (Relax NG)128.
Moreover, the documentation of the schemas must ensure that the constituent parts are
interpreted in a uniform manner. For instance, it must be documented whether an element,
e.g. "Street", also includes the house number within an address, or whether an element, e.g.
"First name", can contain several first names or the forename used only.
Sensible processing of the data content hence often requires prior definitions via the
schemas. For instance, in order to make it possible to compare details of occupations, it is
necessary to define certain spelling and wording, because software simply comparing the
profession of an "interpreter" and "translator" will not find any match. If, however, the use
of the standard classification of occupations by the German Federal Pension Insurance were
specified, all data records for translators as an occupation would be given the value "8220".
This would make it possible to compare data and semantic interoperability would be
established. The use of such uniform code lists is hence a suitable way to establish semantic
interoperability. In addition to this, the use of code lists also improves the quality of the data
to be processed. The codes presented in the selection lists prevent, for instance, wrong
spellings and non-plausible data from being entered in the free-text fields.
5.2
Purpose of standardizing data models
As already shown in section 5.1, the definition of XML as the standard for data description in
SAGA129 merely secures technical interoperability for the interchange of data between
applications. Due to the flexibility of XML, however, this definition alone is not sufficient to
ensure the standardization of data models. The components of data models especially, for
instance, the address and name of an individual, which occur in many different
eGovernment applications, are presented in a number of ways. There is no semantic
interoperability since the data model in each application can be described in a different
manner in XML. Standardizing these data models can help to avoid variants and improve
the interoperability of applications based on the same standardized data models. First
results with the standardization of data models have already been achieved.
Private sector standardization projects have shown that any attempt to achieve full-scale
standardization of data models is usually doomed to fail. The standardization activities
within the scope of Deutschland-Online hence focus on communication interfaces for
electronic data interchange in two separate areas. The first area is the standardization of
specific data models and the second area is the standardization of general data models, socalled core components.
Specific data models
Specific data models are understood to be those data models which have a strong reference
and which can usually only be used in one area of application even if several public
128 Refer to section 8.3.2 "Interchange formats for data models” on page 96
129 Refer to section 8.6.6 "Interchange formats for data ” on page 109
SAGA 4.0
57
agencies may be involved in the exchange of specific data. One example of such a data
model is "XMeld" from the field of citizen registration services.
General data models
Contrary to specific data models, general data models – also referred to as core
components130 – are data models that are used in many different areas of application.
Examples of such data models are "Name" and "Address".
5.3
The Deutschland-Online
"Standardisierung" [Standardization]
project
5.3.1
Task and project aim
No. 2 of the Deutschland-Online action plan131 finds that binding, uniform standards for
data interchange are a vital precondition for consistent electronic business processes in the
public administration in Germany.
In light of this, the Deutschland-Online "Standardisierung" [Standardization] project was
set up as one of six prioritized Deutschland-Online projects and handed over to the Federal
Government (represented by the Federal Ministry of the Interior132) and the federal Land of
Bremen (represented by the OSCI steering group133) as the lead unit.
The purpose of the project is to support and coordinate the development and provision of
technical standards for electronic data interchange (XÖV standards), so that electronic
administration processes can be implemented efficiently and in a uniform manner.
The results of the "Standardization" project will be used predominantly in XÖV projects134.
Common methods, tools and infrastructures are to be created for the XÖV projects.
Examples of such XÖV projects are:
a. "XMeld" (citizen registration services)
b. "XBau" (building/construction)
c. "XJustiz" (electronic legal communications)
d. "XDomea" (workflow management)
e. "XKfz" (vehicle registration services)
f.
"XFinanz" (finance)
130 Refer to section 5.4.4 "Core components” on page 63
131 For more detailed information, please refer to section 4.3.2 "Deutschland-Online - The joint
eGovernment strategy of the Federal Government, federal-state governments and
municipalities.” on page 38 and also refer to http://www.deutschland-online.de
132 Refer to the Co-ordinating and Advisory Agency of the Federal Government for Information
Technology in the Federal Administration, http://www.kbst.bund.de/
133 Refer to the OSCI steering group, http://www.osci.de/
134 Refer to http://www.osci.de/, navigation items "XÖV-Koordination" [XÖV coordination] >
"XÖV-Projekte" [XÖV projects]
58
SAGA 4.0
5.3.2 XÖV working groups
The Deutschland-Online "Standardisierung" [Standardization] project is broken down into
four sub-projects: "Bestandserhebung und Gesamtkonzept" [Stock-taking and overall
concept], "Technische Infrastruktur für XÖV" [Technical infrastructure for XÖV], "XÖVKoordination" [XÖV coordination] and "Kommunikation, Öffentlichkeitsarbeit und
Vertretung in Gremien" [Communication, PR work and representation in committees]. A
more detailed presentation of the overall project can be found in the project manual135.
The "XÖV-Koordination" [XÖV coordination] sub-project has two working groups for the
development of uniform methods and concepts for standardizing specific XÖV standards
and the general XÖV core components:
a. The "Datenkonferenz" [Data conference] working group: In this working group, experts –
above all, federal-agency representatives of the individual XÖV projects (e.g. XMeld,
XKfz) – are working on the identification and definition of general data models (XÖV
core components). This hence ensures that the requirements of the XÖV project, which
already exist, are included in the data standards and the standards created can be
reused in the different XÖV projects. Furthermore, within the scope of the working
group, a procedure was developed for the application and coordination of XÖV core
components. Work on the individual topics was carried out in various sub-working
groups.
b. The "Auslieferung und Implementierung von XÖV-Standards" [Delivery and implementation
of XÖV standards] working group: This working group addresses the practical use of the
completed XÖV standards. The working group is responsible for defining the following:
i.
general rules for describing test cases in XÖV projects in order to check the
compliance of specific IT applications which implement this XÖV standard,
ii.
the name and design rules for XML schemas,
iii.
concepts for using and updating code lists, as well as
iv.
the procedure in the event of a change of XÖV standards.
5.3.3 XÖV framework
The XÖV framework136 describes a procedure model based on the V-Modell XT137 for
implementing XÖV standardization projects. The various project phases which an XÖV
project should pass through are described along with the rules for the successful
completion of these phases, refer to Fig. 5-1.
"Priorisierte Vorhaben" [Prioritized projects] > "Standardisierung" [Standardization] >
"Downloads & Informationen" [Downloads & Information] > link "Projekthandbuch"
[Project manual]
136 Refer to XÖV-Framework v1.0 - Leitlinien für die XÖV-Standardisierung [XÖV Framework
v1.0 – Guidelines for XÖV Standardization], October 2006, Fig. 1, http://www.deutschlandonline.de/, navigation items: "Vorhaben" [Projects] > "Priorisierte Vorhaben" [Prioritized
projects] > "Standardisierung" [Standardization] > "Downloads & Informationen"
[Downloads & Information] > link "XÖV-Framework" [XÖV Framework]
137 Refer to the XT V model, http://www.kbst.bund.de/v-modell and section 1.6 "Relationships
with other eGovernment documents” on page 13
SAGA 4.0
XÖV goals
Improved interoperability
59
Rules for XÖV projects
The possibility to use existing,
specific modules was examined.
The project order includeds a
benefit assessment.
XÖV project types
Process-orientated
XÖV-expanded
projects
(E projects)
Lower project risks
Processes were standardized also
across administrations.
Lower costs of XÖV
standardization
XGenerator was used to create
schemas / documentation.
Data-orientated
XÖV basic projects
(B projects)
…
supports
is a mandatory rule for
is an optional rule for
Figure 5-1: Goals, rules and project types in the XÖV framework
The aim is provide uniform quality and evaluation criteria for the status of current and
future XÖV standardization projects. Uniform evaluation criteria, on the other hand, are an
important precondition for the binding recommendation of XÖV standards and hence for
the use of the project results and the success of the standardization projects.
The main goals of the XÖV Framework are:
a. to improve interoperability,
b. to reduce costs through reusability, and
c. to reduce project risks by exchanging experience and learning from best practices.
The XÖV Framework distinguishes between two types of XÖV projects:
a. XÖV base projects (B projects): The aim of B projects is to create a standardized data
model or an XML schema.
b. XÖV expanded projects (E projects): E projects go beyond the aim of B projects and
attempt to improve and standardize inter-agency processes (XÖV standards, for
instance, for XMeld).
5.4
Support for data model developers
Due to the growing networking of applications, securing semantic interoperability
through suitable data modelling is becoming more and more important. Data modelling in
complex eGovernment projects poses ever-greater challenges for those in charge of such
projects. In a first step towards standardized data models, the Federal Ministry of the
Interior is supporting developers of data models through measures which are described
below, refer also to Fig. 5-2.
60
SAGA 4.0
Guide
document
Recommendations for action
and assistance
Feedback
Generation of
XML schemas and
documentation
Basics for semantic
interoperability
Core
components
Project-specific
requirements
Modeller
Identification of relevant
data models
Project-specific
requirements
XGenerator 2.0
Import of own
data models
XRepository
Figure 5-2: Support for data model developers
5.4.1
Guideline for developers of process and data models
On its website, the KBSt offers a guideline for developers of process and data models138. This
guideline provides those in charge of projects with practical assistance and
recommendations for action during their day-to-day work, and describes how high-quality
data models can be developed.
The guideline is designed to address the entire process modelling and data modelling
complex. It also features information on how to prepare modelling, on modelling itself, and
on analyzing and optimizing existing models. All these topics are addressed in the
guideline and illustrated by examples.
5.4.2 XML Infopoint and XRepository
The KBSt unit also provides another tool on its homepage, i.e. the XML Infopoint139. This is
where information is gathered on planned, current and completed projects with an XML
reference. Synergies can be achieved and work reduced by making use of information
publicly available as well as specifications of projects with a similar topic, or by contacting
those in charge of other projects.
In Spring 2008, XML Infopoint is to be replaced by XRepository.
138 Refer to "Leitfaden für Entwickler von Prozess- und Datenmodellen" [Guideline for
developers of process models and data models], KBSt, 2007,
http://www.kbst.bund.de/modellierungsleitfaden
139 Refer to XML Infopoint, http://www.kbst.bund.de/xml-technologie
SAGA 4.0
61
The main aim of XRepository is to publish specific and general data models140, so that they
can be reused in projects, thus leading to savings and improved interoperability. A focus is
also placed on standardized data models (XÖV standards and core components).
In order to obtain a large content base, the obstacles to the inclusion of data models are
kept as low as possible. This can, however, be opposed by the demand for higher quality.
XRepository will hence be set up on several levels, refer to Fig. 5-3.
COLLECTION
Specific data
models
General data
models
Proposal list for specific
data models
Proposal list for general
data models
Quality assurance
CATALOGUE
Positively rated specific
data models
Recommended
XÖV standards
REJECTION LIST
of rejected data models
Positively rated general
data models
Standardization
STANDARDS
Rejection
Rejection
Recommended
XÖV core components
CONTINUANCE LIST
Data models to be
retained
Mapping, if
necessary
Figure 5-3: Standardization process in XRepository
The first level is a collection which includes the required broad base of data models.
Registered users can include models here without significant obstacles. Only a brief preexamination is designed to prevent the inclusion of irrelevant or unsuitable content. Users
of XRepository are informed that when these models are used, high quality and
compatibility with future standards are not warranted. Despite this, by reusing the models
from the XRepository collection, savings can be made since double work is avoided. Using
models from the collection is particularly good when no interoperability with other
systems is required.
In order to achieve high quality despite the low requirements for the XRepository
collection, a second level will be introduced: a catalogue of quality-assured data models.
This catalogue only includes those models from the collection which fulfil defined quality
requirements141.
In the third level of XRepository, the standards, i.e. the XÖV core components (general) and
the XÖV standards (specific), will be included. The standardized data models fulfil the
140 Refer to section 5.2 "Purpose of standardizing data models” on page 56
141 The quality requirements will be described in detail on the homepage following
publication of XRepository.
62
SAGA 4.0
quality requirements of the catalogue. Care will be taken to ensure that no data models
exist in the catalogue which compete with the standards. A continuance list will be set up
for those models of the catalogue which will be replaced by standards. Data models in this
continuance list can still be used. New projects, however, should use the standards. In order
to make it easier to replace established models of the catalogue with standards, migration
instructions can be provided in XRepository which facilitate the transfer of established
models to XÖV core components or XÖV standards, respectively. Mappings could enable
the use of standards for data interchange without having to internally replace established
data models.
The use of the standards for data modelling shown in XRepository is recommended
particularly for those eGovernment applications which involve data interchange across
agencies and across applications.
The standardization of data models – and especially the development of core components is being promoted not just in Germany, but also on an international level, and repositories
are being created for their dissemination. On international level, UN/CEFACT is the leader
in the development of core components142. As soon as German standards come into contact
with international data traffic, an exchange with international standardization projects
will be sought at an early point in time.
5.4.3 XGenerator 2.0
XGenerator 2.0143 is a tool provided by the Federal Ministry of the Interior that can be used to
automatically generate specifications for XML-based data interchanged from UML models.
These specifications can be made available in machine-readable form to the software
implementations.
A specification in this case consists of a number of machine-readable XML schemas and
documentation for the application developer which is consistent with this. The use of
XGenerator 2.0 avoids the difficult, manual updating of the schemas and the
documentation which would otherwise be necessary. In the event of modifications of the
specific model, XGenerator 2.0 can be used to automatically generate the new XML
schemas and the documentation.
XGenerator 2.0 offers the following functions, refer to Fig. 5-4:
a. Validation of the UML models against the XÖV-UML profile144
b. Automatic generation and validation of XML schema files from UML models
c. automatic generation of DocBook files145 from UML models
142 Refer to Core Component Library,
http://www.unece.org/cefact/codesfortrade/codes_index.htm#ccl
143 Refer to XGenerator 2.0, http://www.kbst.bund.de/xgenerator
144 A UML profile is a standard mechanism in order to individually expand the UML
specification. The XÖV-UML profile defines, among other things, a number of specific
additional annotations (stereotypes) in order to generate XML schemas and to steer their
documentation, refer to http://www.osci.de/, navigation items: "XÖV-Koordination" [XÖV
co-ordination] > "XÖV-UML-Profil" [XÖV-UML profile].
145 DocBook is an open document format that was standardized by OASIS (Organization for the
Advancement of Structured Information Standards) and is ideally suited for generating
print and online formats, e.g. PDF and HTML.
SAGA 4.0
Specialist group
defines the
specific model
UML model
63
Specification developer
adds information for the
generation of schemas and
their documentation
Documentation
XGenerator
generates
Refined specific model
with an XÖV UML profile
XML schema
Figure 5-4: How XGenerator 2.0 works
5.4.4 Core components
The media-consistent electronic exchange of data, also across various fields, calls for
general, standardized data models, for example, when personal data is to be exchanged
between citizen registration and vehicle registration services. The United Nations Centre
for Trade Facilitation and Electronic Business (UN/CEFACT) developed the Core
Components concept precisely for this purpose. Within the scope of the DeutschlandOnline "Standardization" project, a series of core components were created and presented
to the Co-operation Committee for Automatic Data Processing for the Federal-government,
Federal-state Government and Municipal Administration Sector (KoopA ADV) for its
approval and were subsequently made available to Germany's administration. These core
components include, among others:
a. Natural person
b. Name of a natural person
c. Organization
d. Authority
e. Address
f.
Gender
g. Religion
h. Marital status
i.
ID document
64
j.
SAGA 4.0
Language
k. Country
l.
Time period
Developers of data models can use these core components as templates and, by omitting
attributes, can restrict value ranges and/or quantities in order to create a specific
component which meets the requirements of the respective data interchange. Redundantfree modelling (information cannot be stored in different elements) and clear
documentation of the core components help to ensure that data can be exchanged without
human intervention. The core component "address", for instance, ensures that the house
number is an attribute of its own and may not be saved together with the name of the street.
The only way to avoid conflicts in automated data interchange is to ensure that all
communication partners model their data according to the same rules.
The involvement of the XÖV projects in the development of core components ensures that
they fulfil these requirements. The DOL "Standardisierung" [Standardization] project
ensures that new requirements are considered when core components are updated and
that additional core components are created according to demand.
Final versions and drafts of core components and specific components are to be stored in
future in the so-called XRepository and are to be made generally available.
SAGA 4.0
6
65
Computational viewpoint:
Reference software architecture
The computational viewpoint according to RM-ODP146 describes the architectural structure
of distributed eGovernment applications in abstract form and omits implementation
details. In this chapter, issues of architecture are explained and the resultant reference
software architecture is presented. This chapter also offers assistance for designing and
developing long-term eGovernment applications for the federal administration which are
suitable for operation, maintenance and further development.
The term "Reference Software Architecture" refers to an ideal architecture type of the
federal administration. It describes the design layout of eGovernment applications
(specifically: services147 and systems148) of an administration or – more generally – of an
organization.
Section 6.1 describes the general, non-functional requirements for developing applications
which must be viewed independent of use in eGovernment. The extent of these
requirements influences the architecture decisions to be made.
Section 6.2 "Implementation options and architecture paradigms" presents the main
alternatives and guidelines for architecture decisions. The options and paradigms reflect
the current state of the art in software architecture.
Finally, a reference software architecture for eGovernment applications is developed in
section 6.3 based on the requirements and alternative solutions contained in sections 6.1
and 6.2.
6.1
General requirements for software
applications
The computational viewpoint in SAGA provides assistance when developing eGovernment
applications with a view to the aims identified in SAGA149 and to the guidelines and
requirements presented within the scope of the examination of the enterprise viewpoint in
chapter 4.
In addition to the specific functional requirements for developing an eGovernment
application, which can be derived, for instance, from the technical specification, there is a
series of general requirements which are relevant for the architecture. The following list of
such non-functional requirements is arranged alphabetically and does not reflect any
146 Refer to chapter 3 "Architecture model for eGovernment applications”, section 3.4
"Computational viewpoint” on page 34
147 Services are entities which provide functionalities for applications. The use of services also
makes it possible for external applications to manage the resources provided by the service.
Services are specified via their interfaces and the functionality made available.
148 Systems are entities which provide the user with complex functionalities. If necessary, they
use the services made available.
149 Refer to section 1.3 "Aims” on page 12
66
SAGA 4.0
weighting of the individual requirements with a view to software and technical aspects150.
However, the aims of interoperability and reusability laid down in SAGA have an
outstanding role to play.
a. Extendibility
Extendibility refers to the economically reasonable ability to add new functionalities to
the system, or to extend the existing functionality without any adverse effects on such
functionality. Especially if eGovernment applications are operated over a long period of
time, it must be possible to extend them as laws change.
b. Flexibility
"Flexibility" generally refers to the ability to modify an architecture in order to meet
with new, non-functional requirements in a cost-efficient manner. A topology that can
be changed permits quick modification of a distributed architecture and hence
improves non-functional requirements, such as availability, reliability and scalability.
c. Interoperability
Interoperability refers to the media-consistent implementation of transaction services
between special inter-agency applications. One organizational precondition for this is
that the administration processes must be harmonized so that the eGovernment
applications implemented can interact with each other.
d. Openness
The "openness" feature of an eGovernment system is one of the crucial factors for its
successful use. In order to allow existing and new systems to be easily integrated into
other systems, such systems must have clearly defined and documented interfaces or
must be so encapsulated that they can be at least integrated via portals.
e. Performance
The "performance" feature of a system generally refers to the ability to execute
functionality quickly enough to warrant the usability of the system.
A measure for performance is the capacity of a system, i.e. the ability to process a
defined number of jobs per time unit.
f.
Security
Security describes the assurance that information can only be modified or published in
compliance with the proclaimed security policy.
Confidentiality, authenticity and traceability, as well compliance with the Federal Data
Protection Act and the relevant chapters on security in the eGovernment manual must
be ensured in the use of online services, refer also to chapter 8.1 "IT security concept" on
page 91.
g. Scalability
Scalability refers to the ability to warrant the desired operating efficiency and
scalability even as the degree to which an application is used grows. It must be possible
to easily distribute the application or its components.
h. Availability
Availability is a measure that shows how reliably an application makes functionalities,
services or resources available.
150 Refer to [KBSt 2007]
SAGA 4.0
67
i.
Updating capability
eGovernment applications suitable for updating feature economically efficient
operation and updating. Efficient updating must be possible for external technicians
who were not involved in the development of the application without requiring
extensive familiarization or training.
j.
Reusability
Reusability refers to the repeated use of an application or its components with the same
or similar services. This avoids redundant development. Reuse is possible on several
different levels of abstraction, e.g. exchange of experience between agencies and the
use of joint data and process models, architecture patterns and central services.
The concrete weighting of the different requirements depends on factors which must be
identified and evaluated when developing the concept for the individual eGovernment
applications. In the case of applications with very high access rates, for example,
availability is likely to be more important, whereas security issues are more likely to have
priority in the case of approval and licensing procedures.
Additional information can be found in the federal administration's "ITArchitekturkonzept für die Bundesverwaltung" [IT architecture concept for the federal
administration] [KBSt 2007].
6.2
Implementation options and
architecture paradigms
The following sections discuss the implementation options and architecture paradigms
which should be observed when implementing eGovernment applications or which should
be used to select suitable options. The options and paradigms reflect the current state of the
art. Additional information can be found in the federal administration's "ITArchitekturkonzept für die Bundesverwaltung" [IT architecture concept for the federal
6.2.1
Component-based development
A component is understood to be a software entity which can be used without the need for
modification in software applications which are beyond the control of the component
developer. Users normally do not have access to the source code of a component, however,
they can adapt the behaviour of the component in the manner foreseen by the developers
of the component.
Components offer their functionalities via export interfaces and, if necessary, can use the
functionalities offered by other components in order to implement the functionalities
offered; the use of these functionalities is specified in the import interface, refer to Fig. 6-1.
Since the description of the functionalities offered and consumed by a component is
independent of the actual implementation, implementations may be exchanged without
the user realizing this and this offers many possibilities for the further development of the
implementation.
68
SAGA 4.0
Component platform
Component 1
Component 2
Export interface
Export interface
Body
Body
Import interface
Import interface
Figure 6-1: Component-based development
Another major improvement compared to purely object-orientated concepts is offered by
standardized runtime environments for components in the form of application servers or
light-weight frameworks which enable the declarative use of special, independent services,
such as authorization, localization, persistence or transaction management for
components. Since these functionalities no longer have to be implemented in the
components, software creation is both easier and faster. Furthermore, the exchange and
simple reuse of components is possible as contemplated in the paradigm for separating
concerns in other application contexts. In order for components to be able to use the
functionality of a platform, special component platform contracts must be implemented,
i.e. components are always implemented for precisely one type of component platform.
6.2.2 Service-orientated software architecture
The term "service" refers to a concept from the business process modelling context which
stands for the repeated execution of business activities. The approach described below
requires services to be stateless – contrary to component-based development. Fig. 6-2 "SOA
reference model" on page 69 provides an example of service rendering and service use in a
Service Oriented Architecture (SOA). The individual levels in the illustration are merely used
to show the logic breakdown and do not represent any tiers in the sense of a tier model.
Service use
SAGA 4.0
69
User
Business processes
composed of activities
Service interface
atomar and composed
Components
Service delivery
for implementing services
Service 1
component
Service 2
component
OFA service
component
Operating infrastructure
and data management
DBMS
Legacy
system
ERP
system
Figure 6-2: SOA reference model
Services make their functionalities available via interfaces (dark circles with a bright border
in the middle of Fig. 6-2). How the functionality is performed is irrelevant for the user. The
functionality of newly implemented services is carried out by components. Using
connectors, the functionality of existing systems is subjected to modular encapsulation and
made available as a service.
Users (bright circles with a dark border in the upper section of the Fig. 6-2) use the services
either directly or integrate these into their business processes. These processes (white
border) result from the composition of individual activities (circles). The activities use other
activities within a composition. Each activity requires either manual access (light circle) and
or can be mapped by services (dark circle). This mapping can be carried out on a standalone service or a composition, i.e. a combination of services (symbolized by the border
around two service interfaces). The composition of existing services offers a higher value
service for the business processes and users.
The technical strength of a service oriented architecture is that it makes it possible to
combine existing functionalities irrespective of the technologies used to implement these
functionalities. A service oriented architecture, however, must meet with certain
preconditions:
a. For interaction between services and their users (the arrows in Fig. 6-2 in the direction
of service interfaces and their compositions), a communication basis must be defined
which is rooted in generally accepted standards151. The service must master these
standards, so that it can be used.
151 Refer to section 8.7.1.2 "Middleware communication with applications outside the
administration” on page 123
70
SAGA 4.0
b. Potential users must be able to receive information about the services available. A
repository can provide this information and hence enable uniform access to services.
From an economic point of view, the service oriented architecture reduces the costs of
developing and operating applications if a larger number of services are made available
and are used by many applications. This then reduces the time and work involved in
developing new applications because only the functionality which is not yet covered by
existing services now has to be implemented. The central operation of services, in
particular, helps to reduce costs thanks to a more economic use of resources and lower
manpower demand.
A directory of electronic services for the public administration is being implemented by the
Deutsche Verwaltungsdiensteverzeichnis (DVDV) [German Directory of Administrative
Services]. This is where the connection parameters of the services, which are required for
use, are saved, refer to section 7.4.1 on page 88.
6.2.3 Multi-tier architecture
The following section explains why both component-based as well as service-based multitier architectures support compliance with the requirements set forth in section 6.1.
Separation of business and data storage logic
The separation of business and data storage logic minimizes the dependency of systems or
services on database manufacturers. In response to growing requirements, e.g. concerning
performance or availability, the database can be exchanged without having to change the
business logic. In addition to this, the same software can be reused with other database
products with few difficulties.
Separation of presentation and business logic
Separating the presentation and business logic offers a technical solution with optimum
support for multiple presentation channels, such as different browser types or mobile
devices, e.g. personal digital assistants (PDAs). Besides this aspect, the separation of
presentation and business logic significantly enhances the structure of the architecture,
thereby substantially improving updating capabilities, trouble-shooting, flexibility,
reusability and reproducibility whilst at the same time lowering costs in the medium term.
Furthermore, such a separation enables the potential distribution of the application to
several servers – where one server is responsible for the presentation tier and a second
server for the business logic – and it is from here that the services are triggered which in
turn can run on other servers. This has a positive impact on operation with regard to
security, upgrading capability and scalability. Special attention should be paid here to
communication because a less-than-optimum distribution adversely affects performance.
Separating client and presentation logic
In order to avoid having to install a separate client software for each application, uniform
access is recommended via the browser, refer to section 8.5.1 "Access to information with
computers" on page 101. Since barrier freedom and security require that eGovernment
SAGA 4.0
71
applications remain usable even if all active contents have been deactivated at the client
end, the data must be processed at the server end in a separate presentation tier. Different
presentations can be generated for different clients on the basis of the respective
requirements.
Multi-tier architecture
The separation of client, presentation logic, business logic and data storage logic leads to a
multi-tier architecture:
Security
Presentation
Middle tier
Integration components
Communication
Client
Persistence / Backend
Figure 6-3: Structural view - multi-layer architecture
a. The client tier is where users and software interact. The data processed by the
presentation logic as well as the user interface is visualized. The client tier hence
represents different access channels reflecting different users, devices, transmission
paths, as well as different application purposes in order to interact with special
applications. SAGA refers to the following terminal devices:
i.
Web access via web browsers or special browser plug-ins
ii.
Mobile phones and personal digital assistants (PDAs)
iii.
External applications (e.g. ERP systems)
b. The presentation tier implements the processing of application data for the client (e.g.
as a website) and the interaction between the user and the special application. The
presentation tier includes all the standards for communication with the relevant
terminal devices of the client tier.
c. The middle tier, also referred to as the business tier, implements the business logic
irrespective of its presentation and processes the data from the persistence tier. This is
carried out on the basis of services and by components when services are unable to
perform this. This is where the program sequence is controlled and this steers
interaction between the services and components.
d. The persistence tier is responsible for the storage of data objects. It abstracts from the
database. The backend is the collective term for functionalities of the operating system,
72
SAGA 4.0
specific databases as well as existing, non-SAGA-conformant special applications,
legacy or ERP systems.
6.3
Reference software architecture for
Interoperability, reusability, economic efficiency, openness and scalability are the key
requirements for eGovernment applications152. The reference software architecture
described is based on implementation options and architecture paradigms from section 6.2
which, in turn, are used to fulfil the general requirements contained in section 6.1. This
architecture is based on multi-tier architectures and permits both the use of services as well
as the direct use of components. Implementation should be object-orientated153.
6.3.1
Architecture decisions
Due to the heterogeneous requirements of the different public agencies, it does not make
sense to define a reference software architecture based on just one architecture paradigm
to be used for all applications. Instead, the approach which is most suitable must be sought
for from case to case.
The possibility of a service-orientated approach154 should always be examined because this
permits a high degree of flexibility, interoperability, reusability and openness. If an
organization introduces a service oriented architecture, this usually requires close cooperation between IT and technical staff in order to document existing business processes
and to identify suitable services. The advantages of the new approach then become
particularly obvious when existing processes are revised with a view to the new
architecture.
Compared to component-based architectures, service oriented architectures require an
additional abstraction level. This abstraction is achieved with communication protocols
which are supported by all component platforms. These protocols then usually have a
restricted functionality and are less performant than special platform-specific
communication platforms. Under the following circumstances, it is advisable to implement
a component-based architecture rather than a service oriented architecture:
a. The requirements placed on the performance of the application cannot be
implemented by a service oriented architecture (e.g. response times).
b. The business processes to be supported are so complex that single activities can no
longer be implemented as stateless services.
c. The flexibility of the service oriented architecture is not required.
Detailed recommendations for selecting the suitable architecture paradigms can be found
in sections 3.4 "Architekturentscheidungen" [Architecture decisions] and 4 "Fallbezogene
Architekturentscheidungen" [Case-related architecture decisions] of "IT152 Refer to section 1.3 "Aims” on page 12
153 Refer to [KBSt 2007], section 3.3.1
154 Refer to section 6.2.2 "Service-orientated software architecture" on page 68
SAGA 4.0
73
Architekturkonzept für die Bundesverwaltung" [IT architecture concept for the federal
6.3.2 Introduction of a service oriented architecture
The following section addresses the organizational challenges and the aspect of costs for
the introduction of a service oriented architecture.
The main organizational challenges
a. The introduction of a service oriented architecture is a complex process because the
application landscape is marked by a number of existing systems and there is little
room for new development or adaptation. This is why such an introduction can take
considerable time. The introduction should be carried out gradually, beginning with a
pilot project.
b. A host of reusable services are created when services are developed not for a specific
application but for many applications in terms of an overall IT structure within the
meaning of a development plan for the entire application landscape. This calls for an IT
architecture management function which is responsible for the planning and design of
the overall IT architecture, refer to "IT-Architekturkonzept für die Bundesverwaltung"
[IT architecture concept for the federal administration] [KBSt 2007]. IT architecture
management is an ongoing process which involves both strategic and operational
elements.
c. In contrast to customary architectures or architectures with largely closed individual
applications, service oriented architectures have other, frequently more complex
requirements or challenges regarding security. In a service oriented architecture, it is
no longer the IT security of the individual special applications which has to considered,
instead that of all services involved in a special application, which may be operated in a
distributed manner, must be considered. These requirements must already be
coordinated in the development process with distributed responsibilities and then later
in operation.
d. Parallel development of services in different projects, which are to be used together in
one application, calls for project-spanning project management, i.e. multi-project
management. This is the only way in which project-spanning requirements can be
fulfilled.
e. The project-spanning nature of a service oriented architecture has implications for the
organization and performance of testing, for instance, due to a version change in a
service. All applications using the service are then affected by test activities.
f.
The independent further development of services by various suppliers means that
changes must be coordinated within the scope of a change management system for all
applications. Rules must be defined for new versions of services (release policy), such as
the scope and the related test work for all suppliers.
g. Distributed responsibility for the development and operation of services calls for a
Service Level Management for a suitable and economically sensible level of IT services,
although when it comes to specific services, SLAs (Service Level Agreements) must be
74
SAGA 4.0
concluded between service users and service providers. IT operations must be
organized in a process-oriented and service-oriented manner. The recommendations of
the ITIL155 provide a suitable basis for this.
h. Service orientation calls for the development of new billing models which reflect the
distributed development and distributed operation of the applications or services,
respectively.
The introduction of a service oriented architecture leads to investments, especially at the
beginning, because the use of new principles and technology means that training will be
required for staff and the previously mentioned organizational challenges must be
overcome.
6.3.3 Three-tier architecture for services
Client
When implementing a service with a multi-tier architecture according to section 6.2.3, the
presentation tier is omitted, refer to Fig. 6-4. The reason for this is that the services perform
their functionality from within the business logic, i.e. the middle tier. The user of the service
is another application (client) which may itself be responsible for presenting the results.
Service delivery and service use are carried out as described in Fig. 6-2 "SOA reference
model" on page 69.
Service
user
Communication protocol
Middle tier
Services
platform
Service
interface
Service
components
Persistence /
Backend
Components
platform
DBMS
Legacy
system
ERP system
Figure 6-4: Model of a three-layer architecture of services
155 Refer to section 7.1 "IT Service Management with the ITIL" on page 79
SAGA 4.0
75
6.3.4 Four-tier architecture for eGovernment systems
Client
Fig. 6-5 provides an example layout with a concrete structure for a multi-tier architecture of
an eGovernment system based on the general description in section 6.2.3. It can be seen
that the presentation tier consists of a Presentation Application Server which generates, for
instance, HTML and XML data with Java Server Pages. The Business Application Server on
the middle tier forms the backbone of the application and performs the special
functionalities on the basis of services and components. Via application interfaces (or also
service interfaces as shown in Fig. 6-4), external applications and services can access the
eGovernment system whilst bypassing the presentation tier.
Middle tier
Presentation
Mobile device
Web browser
HTML / XML
Servlets
Java Server Pages
Presentation Application Server
Application
component
Application
interface
J2EE
SOAP
JMS
RMI
Business Application Server
Persistence /
Backend
DBMS
Legacy
system
ERP system
Figure 6-5: Example model of a four-layer architecture of eGovernment systems
Legacy and ERP systems are integrated via the respective integration components. The
systems provide their functionalities via application interfaces or service interfaces.
Connectors may be needed in order to achieve modular encapsulation of the legacy
systems.
6.3.5 Security
In order to implement the requirements for security, the design recommendations
contained in the E-Government-Handuch [eGovernment manual] must be considered. The
76
SAGA 4.0
"Sichere Integration von E-Government-Anwendungen - SIGA"156 [Secure Integration of
eGovernment Applications] and "Sichere Architekturen für Client-Server-Architekturen für
E-Government" [Secure architectures for client-server architectures for eGovernment]
modules in the sub-chapter on "IT und IT-Sicherheit" [IT and IT security] are particularly
relevant. Although designed for component-based implementation, the architecture
principles contained here can usually be applied to service oriented architectures on a oneto-one basis.
6.3.6 Reuse and integration of OFA offers
When designing a new eGovernment application, an analysis is conducted in order to
determine which services and systems have to be newly developed and which existing
services and systems can be used. Special consideration must be given to the OFA services,
OFA systems, infrastructures and OFA concepts on the KBSt website157.
The term "service" refers to a concept from the business process modelling context which
stands for the repeated execution of business activities. The OFA services make their
functionality available via interfaces. The properties of the implementation are fully
abstracted.
Examples of OFA services
a. Payment platform (ePayment)
b. Directory service
c. GeoDataCentre (GDZ)
An OFA system is a uniform whole, a software entity, that makes a complex functionality
available. OFA systems include the following:
a. Form Management System (FMS)
b. Content Management System (CMS)
c. Travel Management System (TMS)
Although the services of infrastructures are not specific to concrete eGovernment
applications, they nevertheless have a key role to play in electronic communications
between public agencies. The following infrastructures are available, for example:
a. Informationsverbund der Bundesverwaltung (IVBV)
[Federal Administration Information Network]
b. Deutsches Verwaltungsdiensteverzeichnis (DVDV)
[German Directory of Administrative Services]
c. Public-Key-Infrastruktur der Verwaltung (V-PKI)
[Administration Public Key Infrastructure]
An OFA concept describes a generally reusable approach for the implementation of specific
issues in eGovernment applications. The following concepts are available, for example:
156 Refer to [SIGA]
157 Refer to “OFA offers and networks”: http://www.kbst.bund.de/efa
SAGA 4.0
77
a. ArchiSafe
b. Online-Beratung (online consultation)
If the data security OFA system158 is used, a separate client application (the OSCI client
enabler) must be installed at the end of the users of the online service. However, the browser
remains the client of choice for eGovernment applications which is why this scenario is not
part of the reference software architecture.
Client
Mobile device
Web browser
Presentation
Presentation
Middle tier
Middle tier
External
application
Application
interface
Service
interface
Persistence /
Backend
OFA system
Persistence / Backend
Middle tier
Service
interface
ERP system
Persistence /
Backend
Specific application
OFA service
Infrastructure
Legacy
system
ERP system
Figure 6-6: Integration of OFA offers
More complex eGovernment applications come with integration components so that
existing IT applications, such as OFA offers, legacy systems and especially non-SAGA
compliant applications, can be integrated. These integration components – as shown in Fig.
6-6 – are directly located in the middle tier. They offer communication possibilities with
applications, such as ERP solutions, in as far as these applications are not available as a
158 Refer to the data security OFA system ("virtual post office") http://www.kbst.bund.de/efa-vps
78
SAGA 4.0
service and can be triggered via a service interface. In the latter case, no special integration
components are required.
SAGA 4.0
7
79
Engineering viewpoint: IT
service management and
reference infrastructure
This chapter describes operating processes and the establishment of an effective and secure
infrastructure as the Engineering Viewpoint according to RM-ODP159. Today's data
protection, data security, efficiency and availability requirements for eGovernment are
setting high standards for operators of applications and technical infrastructures. This is
why a suitable technical infrastructure has to be set up for the applications from the
physical resources and suitably connected for users through the network level to the
external services which can only be successfully and securely operated within the scope of
ongoing processes of IT service management.
7.1
IT Service Management with the ITIL
As a best practice, the "IT Infrastructure Library" (ITIL) provides an established basis for
designing, implementing and managing essential control processes in IT.
During the preparation of SAGA 4.0, an upgraded ITIL, version 3.0, was issued. In order to
use a tried-and-tested approach as a basis and to be able to refer to German literature, ITIL
version 2.0, which is supported by KBSt documents, is presented in the engineering
viewpoint.
7.1.1
Introduction to ITIL
ITIL is oriented towards customers, services and processes and comprises eight closely interlinked publications on main topics which address support for business processes by IT
processes. IT service management is broken down into the following processes:
a. tactical processes for planning and implementing service requests (service delivery), as
well as
b. operative processes to support the quality and economic efficiency of the services in
day-to-day operation (support service),
which are introduced in brief in a study by BSI and supplemented with synergies with IT
security which is also implemented as a continuous process160.
Successful IT service management requires interaction between the individual processes
whilst mutual control also takes place. ITIL describes in this context the tasks of the
processes, however, the specific demarcation can be chosen according to the specific
circumstances. Since the processes must be continuously operated, this requires concrete
responsibilities. According to ITIL, this means that roles must first be defined for the
respective process managers which must then be filled by individuals. An individual can
159 Refer to chapter 3 "Architecture model for eGovernment applications", section 3.5
"Engineering viewpoint" on page 34
160 Refer to [BSI 2005]
80
SAGA 4.0
assume several roles in this context as long as this does not result in a conflict of interest and
representation is secured. This means that when ITIL is introduced, the coordination of
processes and responsibilities must begin.
SERVICE DESK
SERVICE DELIVERY
SERVICE SUPPORT
Service Level Management
Incident Management
Availability Management
Problem Management
IT Service Continuity
Management
Capacity Management
Configuration Management
Change Management
Release Management
Finance Management
Figure 7-1:Overview of ITIL processes
The ITIL processes communicate with each other via commonly used information
collections. The control of the processes depends heavily on reporting which is integrated
into all ITIL processes in order to assure quality. Object success control is also supported by
ITIL through the use of so-called key performance indicators.
7.1.2
Tactical IT Service Management processes (Service
Delivery)
For eGovernment applications as services, concrete service requests by customers must be
planned and lastingly implemented. For this purpose, ITIL calls for the operation of the
Service Delivery processes.
Service Level Management
When developing a new eGovernment application, the service provider and the customer
negotiate customer requirements as a concrete service offer in a service agreement (Service
Level Agreement, SLA). This is where functionalities, as well as non-functional
requirements, such as performance (according to the number of users active at the same
time) or availability (with maximum downtimes and recovery times), are co-ordinated. The
aim is to draw up a clear definition of the expectations of both sides regarding a new
SAGA 4.0
81
service. In addition to the first-time creation of an SLA, subsequent customer requests and
the monitoring of compliance with the SLA are also handled by the Service Level
Management process. This process steers and monitors both the performance and the
quality of a service.
Availability Management
Availability Management steers the functional provision of eGovernment applications
during the required working hours. The aim is to achieve cost-efficient control of
uninterrupted availability in line with business requirements. Dependencies on external
service providers, e.g. due to maintenance agreements, must also be considered.
IT Service Continuity Management (ITSCM)
IT is an important production factor; its continued functioning must be planned in IT
Service Continuity Management (ITSCM) even under the impact of disasters in the ITIL
process. This is carried out within the scope of Business Continuity Management (BCM)
which ensures that the business processes are restarted in order to secure the required
minimum production capacities.
Capacity Management
The economic use of IT resources should be controlled on a long-term basis for competitive
services using the ITIL Capacity Management process.
Financial Management
Controlling costs for eGovernment applications and hence planning and controlling
economic efficiency, e.g. in a budget process, are carried out by the ITIL Financial
Management process. This can also manage the billing of services to customers.
7.1.3
Operative IT Service Management processes (Service
Support)
The service quality of eGovernment applications can only be steered in conjunction with
the operative side. The IT services are performed on a day-to-day basis by the ITIL Service
Support processes.
Service Desk
Effective communication with customers is an efficient precondition for the successful
operation of eGovernment applications. This means that customers or users must be
provided with quick and simple contact to IT. According to ITIL, this means that a central
point of contact, the Service Desk, must be set up in order to bundle communications
economically whilst providing ongoing user support. In the case of eGovernment
applications, communication with citizens can also take place via the Service Desk. In order
to boost acceptance, it should be possible to reach a service desk through a number of
different communication paths, such as telephone, email, or web applications.
82
SAGA 4.0
Incident Management
Reports of incidents, as well as general queries, must be collected and promptly handled.
The ITIL Incident Management process receives reports from users, responds by ensuring
consistent handling with the least possible annoyance for the user, and informs the user of
the status of trouble-shooting activities. In order to ensure a high degree of satisfaction
among users, trouble-shooting as set forth in the SLA (refer to "Service Level Management"
on page 80) is monitored on the basis of the support level and, if necessary, stepped up by
way of escalation. Incident management should be supported by software, such as a
ticketing system (also referred to as a trouble ticket system), in order to be able to manage
messages and communicate these to other processes and also in order to evaluate them.
Incident management also includes reports on security incidents and is hence of
considerable importance for information security161.
Problem Management
If immediate and clearly identification of incidents and trouble-shooting are not possible,
Incident Management can restore the service quickly for the user with a bypass solution. At
the same time, however, Incident Management commissions the ITIL Problem
Management process to search for the fault. The elimination of the causes of the incident,
which can also be carried out proactively, improves the reliability and economic efficiency
of IT services.
Configuration Management
The operation of eGovernment applications requires an information basis for all IT service
management processes. The ITIL Configuration Management process manages
information concerning the properties and relationships of all components of the IT
infrastructure. This also includes archiving master copies of the software used. The other
ITIL processes can use this information or can also report changes in configuration.
Change Management
Applications, infrastructure, documentation, processes and methods must be modified and
amended in order to further develop IT or eliminate the causes of incidents. The ITIL
Change Management process is used to steer and control these changes. One key aspect
here is agreement among all those involved about the expected effects of the planned
changes in a so-called change-release committee (Change Advisory Board, CAB). Release by
the CAB is a prerequisite for reducing, to a reasonable level, the risk of endangering the
availability of IT services as a result of change conflicts. Changes must be tested and secured
through suitable fall-back procedures. A regularly updated change calendar simplifies
coordination.
Release Management
Infrastructures are further developed in new releases. The ITIL Release Management
process covers the planning, design, generation, configuration, testing, acceptance and
161 Refer to [BSI 2005]
SAGA 4.0
83
putting into operation of a software or hardware version for a production environment.
Releases must be planned in line with a version policy, adequately tested prior to release
and, in order to secure ongoing operations, taken into production (roll-out) under the
control of Change Management. Release Management is linked to IT procurement and to
contract managements as described in the KBSt publication series (e.g. "ITIL and IT
procurement"162).
7.1.4
IT security
IT security is an important basis for successful eGovernment applications. For this purpose,
a separate dedicated publication on Security Management is issued in ITIL which refers to a
far-reaching linking of the Security Management process with the IT Service Management
processes. Furthermore, with a view to security management, ITIL also refers the BS 7799163
standard by the British Standard Institution; their recommendations are considered as the
international standard ISO/IEC 279001 in the BSI's IT-Grundschutz [IT Baseline Protection] in
BSI-Standard 100-1.
Generally speaking, the recommendations by the German Federal Office for Information
Security (BSI) on the security of eGovernment applications164 and the BSI's IT-Grundschutz
[IT Baseline Protection] (former IT-Grundschutzhandbuch [IT Baseline Protection
Manual])165 must be taken into consideration here. When planning eGovernment
applications, IT security must be included from the very beginning166. In the interest of
economic efficiency, IT security measures must be reasonable. A protection requirement
report, like the one recommended in BSI-Standard 100-2167 should be drafted as early as
possible in order to serve as a basis. Such a protection requirement report classifies the IT
infrastructure on the basis of possible damage in the protection requirement categories of
normal, high and very high.
When a normal protection requirement for eGovernment applications is found, the
standard measures recommend in the IT-Grundschutzkataloge [IT Baseline Protection
catalogues] can be used. In the case of high or very high protection requirements, a risk
analysis based on BSI-Standard 100-3168 should be additionally carried out with the support
of the IT-Grundschutzkataloge [IT Baseline Protection catalogues]. This can be used not just
to evaluate the extensively described risks but also to adopt extended measures from the ITGrundschutzkataloge [IT Baseline Protection catalogues] or additional measures from the
E-Government-Handuch169 [eGovernment manual] in order to compensate for higher risks.
The work involved in operating a secure infrastructure may not be economically feasible
for smaller public agencies so that it could make sense to outsource this to the computer
centres of external IT service providers of higher-level public agencies.
162 Refer to http://www.kbst.bund.de/itil, box 2Produkte & Dokumente" [Products &
Documents] > "ITIL und IT-Beschaffung" [ITIL and IT procurement]
163 Refer to http://www.bsi-global.com/
164 Refer to the eGovernment manual at: http://www.bsi.bund.de/fachthem/egov/3.htm
165 Refer to IT baseline protection catalogues at: http://www.it-grundschutz.de/
166 Refer to section 8.1" IT security concept" on page 91
169 Refer to http://www.e-government-handbuch.de/
84
7.2
SAGA 4.0
Design of an eGovernment
infrastructure
The purpose of introducing a reference infrastructure in SAGA is to define the
infrastructural preconditions necessary for operating eGovernment applications and the
required system structure. The following goals are to be achieved in line with the protection
requirements by defining parameters for a reference infrastructure in the sense of an
operating environment.
a. Suitable physical protection of systems
b. Suitable availability of systems
c. Suitable security of systems and their components
d. Classification of systems and their components according to separate security zones
Users / External services
External
specific
External
application
specific
User
User
Central
OFACentral
offeringOFA
application
offering
Network
Internet
Extranet,
VPN
IVBV
Network
access
Infrastructure
Information & service zone
Access
control
Access
control
Access
control
Logic & processing zone
Access
control
Data backup
Management zone
Access
control
Access
control
Data zone
External backup
Figure 7-2: Engineering viewpoint of an eGovernment application
SAGA 4.0
85
e. Scalability of systems and infrastructures
f.
Simple service, efficient maintenance and updating of complex systems and their
components by operating personnel
Fig. 7-2 on page 84 shows a general overall view of a distributed eGovernment application
with the user, network and infrastructure areas.
Both the network and the user areas are typically beyond the control of the operator of an
eGovernment application and hence do not form a focal point of interest in this discussion.
The infrastructure area, in contrast, is controlled by the operator and must feature a
suitable system structure in order to meet the operational requirements for eGovernment
applications.
The requirements for a computer centre and its IT infrastructure will be described in the
following sections.
7.2.1
Physical infrastructure
Servers and IT systems must be installed in suitable locations if they are to be protected
against force majeure, such as lightning, fire, water, excessively high temperatures, or
technical failure, such as power outages, as well as organizational shortcomings, such as
unauthorized access to protected rooms. This is why computer centres planning to operate
eGovernment applications should use the protection requirement report in order to
implement the required IT security measures according to the BSI's ITGrundschutzkataloge [IT baseline protection catalogues]. These measures include, for
instance:
a. Installing IT systems in suitable rooms
b. Controlling access to these rooms
c. Suitable fire detection and fire-fighting systems
d. Suitable power supply systems
e. Suitable air-conditioning systems
f.
Data backup according to the related data backup concept
7.2.2
Zone concept and communication relations
The systems inside the computer centre are located in different zones which are defined on
the basis of the relevant safety and security requirements for the services and data of the
respective zones. In order to ensure that the zone concept covers the general protection
requirements of eGovernment applications, at least the four zones described below should
be implemented within a computer centre's infrastructure. Operation of complex
eGovernment applications may require additional zones. These zones should be adequately
separated according to the basic structures for security gateways170, i.e.:
170 BSI IT baseline catalogues, measure M 2.73, Selecting suitable basic structures for security
gateways, http://www.bsi.de/gshb/deutsch/m/m02.htm
86
SAGA 4.0
a. Any network component (router, switch, hub, etc.) can only be used as an interface
between one zone and another, so that any network component only passes on data
concerning or originating from the two zones directly connected to it. This prevents
any mixing up of data streams in the case of a fault or deliberate attack.
b. A server system can host the systems of a single zone only. This means that distributed
applications must run on server systems in different zones.
c. A server system with eGovernment applications requiring communication connections
to several zones must include a corresponding number of physically and logically
separated network connections (e.g. multiple network cards). This system thereby rules
out a transition from one zone to another.
Information and services zone
The information and services zone covers that part of the network which is located between
the Internet and the other zones of the network. This zone contains servers which can be
accessed by external networks or which, for their part, use the services of external
networks. Further information zones should be set up if systems with different security
levels are to be operated.
In line with protection requirements, communications between the systems of the
information and services zone and the systems of the logic and processing zone should be
protected by encrypted communication channels.
Logic and processing zone
The systems of this zone process data from the data zone and make such data available to
users via systems of the information and services zone. Direct communication between
external networks – such as the Internet – and the logic and processing zone is not
permitted.
Data zone
The data zone contains all the systems where data is stored and made available for longer
periods of time. Access to this zone is permitted from the processing zone and the
management zone only. Direct access from external networks is not permitted under any
circumstances. In the same way, direct access from this zone to other zones is not permitted.
One exception to this is the management zone.
Management zone
The management zone contains all the systems which are needed for administrative
purposes or for monitoring systems in other zones. Furthermore, this zone can also contain
central user administration or authentication services. Access from the management zone
to other zones and vice versa is hence permitted.
Access from within external networks to the management zone is not permitted under any
circumstances.
SAGA 4.0
87
Data backup
Every zone should include its own data backup components. Data of the information zones
should also be backed up in this case via protected communication channels.
7.2.3
Network access and access control
Security gateways control the separation of the individual zones within the computer
centre as well as access by and to external networks. Different technologies can be used for
these purposes.
The interface between the information and services zone and external networks is the most
security-critical point and is hence protected by a combination of multiple security
mechanisms. Different network segments and address areas are separated here on the
network protocol level. Internal network addresses are masked and are hence not
published in external networks. In the case of small networks on an IPv4 basis without a
high protection requirement, this can also be carried out with Network Address Translation
(NAT).
Furthermore, filter mechanisms are in place in order to ensure that access from external
networks is restricted to defined services in the information and services zone. The filter
rules are typically implemented on firewalls or firewall routers which screen the
information in the headers of the incoming data packages on the basis of package filters
and reject unauthorised access attempts.
Furthermore, application gateways can be used which fully isolate communications,
validate data streams on the application level and, when necessary, implement a protocolconforming re-generation of requests.
The communication relations between the internal zones are also controlled by security
gateways. In order to adequately control access to the sensitive areas of the logic and
processing zone as well as the data zone, firewalls should be used because of their
comprehensive filter options. These firewalls work on the basis of dynamic package filters
(stateful inspection) and are capable of monitoring not just individual packages but even
communication streams involving multiple packages. Dynamic package filters enable the
validation of network connections not just on the basis of invariable rules, but additionally
even on the basis of historical communication relations.
Thanks to simple and flexible administration, VLAN technology is the system of choice for
controlling access to the systems in the management zone. For this purpose, all the systems
requiring access to a service in the management zone are combined to form a virtual
network segment (VLAN). In order to prevent unwanted communication between the
individual zones via the VLANs of the management zone, all the systems are fitted with a
second network interface which may not be used for any purposes other than
administration and which is fitted with a package filter.
Using VLAN technology for connecting any zones other than the management zone is not
recommended for security reasons.
88
7.3
SAGA 4.0
Networks as the link between an
infrastructure and external services and
users
The network level is the link between the systems of the computer centre infrastructure and
external services as well as users of eGovernment applications, refer to Fig. 7-2 "Engineering
viewpoint of an eGovernment application" on page 84. This level also contains the Internet,
TESTA (Trans-European Services for Telematics between Administrations), the
Informationsverbund der Bundesverwaltung (IVBV) [Federal Administration Information
Network], the Informationsverbund Berlin-Bonn (IVBB) [Berlin-Bonn Information Network]
as well as other VPN-based networks or extranets. In-house intranets also form part of the
network level. Although a clear consolidation trend has been observed in recent years in
the field of network technologies, many different technologies are still in use. However,
abstraction to higher protocol or application levels can render the system interoperable, so
that SAGA does not give concrete technology recommendations for the network level.
From the point of view of the engineering viewpoint of an eGovernment application,
however, secure and performant communication with the Internet, TESTA, IVBV, IVBB or
extranets has an important role to play in order to ensure reliable access to users and
external services. When eGovernment applications are designed, the necessary
bandwidths must hence be made available on the basis of an assessment of the anticipated
network communication, and the access control mechanisms described in section 7.2.3
must be implemented.
7.4
Access to external services
External services use the infrastructure of eGovernment applications via networks, refer to
Fig. 7-2 "Engineering viewpoint of an eGovernment application" on page 84.
7.4.1
Deutsches Verwaltungsdiensteverzeichnis
[German Directory of Administrative Services]
The Deutsches Verwaltungsdiensteverzeichnis (DVDV)171 [Germany Directory of
Administrative Services] forms a universal infrastructure for eGovernment in Germany. This
is where the addressing parameters of the public administration's online services are stored
in XML format. These are primarily technical descriptions of the services in WSDL format172
as well as supplementary URLs and cryptographic certificates. The DVDV makes it possible
to find all the information required for automated machine-to-machine communication in
machine-readable form. This is the basis for fully automated online services between
machines which are nevertheless secure and legally binding.
171 Refer to http://www.dvdv.de/
172 Web Service Description Language; refer to section 8.7.1.1 "Middleware communication
within the administration” on page 121
SAGA 4.0
89
The LDAP173 directory service standard is the technical basis for this and defines the
structure for the storage and retrieval of DVDV information. The core of the DVDV is the
central federal master which is provided by the Bundesstelle für Informationstechnik (BIT)
[Federal Office for Information Technology], refer to Fig. 7-3. This is the only place where
write access to the data stocks is possible. Data updating is carried out by the connected,
authorised offices in the federal states. The federal master continuously mirrors its data
stock on distributed (e.g. in the federal states) DVDV federal-state servers which share the
query load for the individual data retrievals. OSCI transport protects the updating and
replication of the WSDL files and the supplementary parameters.
TESTA
network
DVDV
fed. state
server 1
Other networks /
Internet
Agency
network /
infrastructure
DVDV
update client
(per fed. state)
DVDV
federal
master
Agency 1
procedure
Agency 2
procedure
DVDVfed. state
server 2
DVDV
fed. state
server n
Clearing
house A
Clearing
house B
Agency 3
procedure
Agency 4
procedure
Agency 5
procedure
Figure 7-3: Structure of the German Directory of Administrative Services
The first application since 1 January 2007 is the implementation of the Framework Act on
Registration, which was revised in 2002, especially the part concerning data transmissions
between federal states. This makes paper-based responses and updating of the civil register
obsolete. Instead, the exchange of data between participating public agencies is exclusively
electronic and automated. Other services already integrated (as per mid-2007) are the
services of the Federal Central Tax Office for communication with the registration
authorities within the scope of issuing uniform tax ID numbers and the municipal core
identity register of the Free State of Saxony. The architecture of the DVDV is designed in
such a manner that any automated communication relationships in eGovernment can
basically use its services.
173 Lightweight Directory Access Protocol, refer to section 8.8.1 “Directory services and
registries“ on page 130; the open source reference implementation OpenLDAP is used for
DVDV, refer to http://www.openldap.org
90
SAGA 4.0
BIT operates the coordination office of the DVDV. This secures the flow of information to
users and service providers. Queries can be sent to the DVDV via the e-mail address:
dvdv@bva.bund.de.
7.4.2
Use of OFA offers
Within the scope of the federal administration's one-for-all offers (OFA offers)174 – broken
down into OFA services, OFA systems, OFA concepts and infrastructures – offers that can be
used by public agencies to integrate their eGovernment applications are made available via
the Internet and via the IVBV.
Services, such as the ePayment OFA service175, can be accessed via the web service interfaces
on the Internet. For this purpose, the OFA service provides the web service interfaces
required at the server end along with a reference implementation for accessing the web
services by the relevant eGovernment application. Communication with external special
applications of other public agencies or enterprises proceed in a similar manner;
middleware communication interfaces may be used for these purposes too.
De-centralized OFA offers, on the other hand, such as the OFA data security systems176 and
the form management system177, are implemented within the computer centre
infrastructure of the different public agencies. The rules already described in section 7.2
"Design of an eGovernment infrastructure" on page 84 should be observed in this case too.
174
175
176
177
Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76
Refer to OFA service - Payment platform ("ePayment"): http://www.kbst.bund.de/efa-zvp
Refer to OFA system - Data security ("virtual post office") http://www.kbst.bund.de/efa-vps
Refer to OFA system - Form Management System: http://www.kbst.bund.de/efa-form
SAGA 4.0
8
91
Technology viewpoint:
Standards for IT architecture and
data security
In this chapter, technical standards are assigned to the individual elements of the
architecture model introduced in chapter 3. Furthermore, this chapter also provides brief
descriptions of these technical standards. If no version numbers of standards are stated, the
version which is most stable from a market point of view should be used, even though this is
not necessarily the latest version.
The meaning of the classifications "Mandatory", "Recommended" and "Under observation"
are described in more detail in section 2.3.1 "Classification in SAGA" on page 20.
8.1
IT security concept
The standards for IT security presented recommend a system approach in order to achieve
and maintain a suitable level of IT security. For this purpose, an IT security concept will be
drafted and further-developed in an IT security management process which will be
continuously operated following its initiation. Since December 2005, the Germany Federal
Office for Information Security (BSI) has recommended and supported an approach in
several BSI-Standards and the IT-Grundschutzkataloge [IT baseline catalogues] which was
previously presented in the IT-Grundschutzhandbuch (IT-GSHB) [IT Baseline Protection
Manual].
8.1.1
Management systems for information security
The first step towards a comprehensive IT security concept requires the creation of a
management system for information security.
Mandatory: BSI-Standard 100-1: Managementsysteme für Informationssicherheit
(ISMS) v1.0 [BSI standard 100-1: Management systems for Information Security]
BSI standard 100-1178 with the general requirements for an ISMS (information security
management system) should be applied within the scope of the security concept. The
standard is fully compatible with ISO standard 27001 and also considers the
recommendations of ISO standards 13335 and 17799179.
8.1.2
IT baseline protection approach
In the interest of the economic efficiency of the IT security concept, only those IT security
measures must be adopted for the IT application and the data to be processed which are
179 Refer to http://www.iso.org/
92
SAGA 4.0
suitable for the protection requirement identified. The system approach for the IT concept
involves steps such as the protection requirement analysis.
Mandatory: BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise v1.0
[BSI standard 100-2: IT baseline protection approach]
In December 2005, the German Federal Office for Information Security (BSI) published its
"BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise"180 [BSI standard 100-2: IT baseline
protection approach]. The standard describes how IT security management can be set up in
practice and operated. It should be used within the scope of the IT security concept. With
this approach, IT security concepts can be created, simply and efficiently, whilst IT security
can be maintained and improved in ongoing operations.
8.1.2.1
Protection aims
Protection aims define the security interests of communication partners in a general form:
a. Confidentiality – protection against disclosure to unauthorized parties:
No data is made available or disclosed to unauthorized individuals, entities or
processes.
Confidentiality is ensured by encrypting the information (cryptography).
b. Integrity – protection against manipulation:
Unauthorized modification or destruction of data is not possible. This includes
information concerning the origin or time of creation.
Integrity is ensured by encrypting the information (cryptography) or by the use of
signatures.
c. Availability – protection against failure of IT systems:
The properties of an entity and/or resource can be accessed and/or used when this is
desired by an authorized entity.
A high degree of availability is achieved through multiplicity, distribution and error
tolerance.
8.1.2.2
Protection requirement categories
The protection requirements must be identified for each IT application of the data
processed. These requirements are a function of the potential damage that can be caused
by impairment of the IT application in question with regard to the protection aims defined
in section 8.1.2.1.
A protection requirement category can be assigned to every protection aim in order to
evaluate applications from a security point of view. In "BSI-Standard 100-2: IT-GrundschutzVorgehensweise" [BSI standard 100-2: IT baselines protection approach], the following
classification is hence made:
SAGA 4.0
93
Protection requirement categories
"Normal"
The impact of loss or damage is limited.
"High"
The impact of loss or damage may be considerable.
"Very high"
The impact of loss or damage can reach catastrophic proportions
and could threaten the very existence of the agency/company.
Table 8-1: Protection requirement categories
One particular aspect which must be considered when determining protection
requirements is whether personal data is processed in order to ensure that data protection
laws are adhered to. SAGA does not explain any data protection measures. The EGovernment-Handbuch [eGovernment manual] (module: Datenschutzgerechtes EGovernment181 [Data-protection-compliant eGovernment]) contains data protection
information with regard to frames of reference, challenges and recommended actions.
8.1.3
Risk analysis
Mandatory: BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz v2.0
[BSI-Standard 100-3: Risk analysis on the basis of IT baseline protection]
BSI standard 100-3182 for additional risk analysis following the IT baseline protection analysis
should be applied to areas with security requirements that go a long way beyond what is
normally required. The reasons for a risk analysis could be a high or very high security
requirement, the use of applications or components not (yet) addressed in the IT Baseline
Protection Catalogues, as well as the operation of application scenarios (environment,
application) not considered in IT baseline protection.
8.1.4
Implementation of the security concept
Mandatory: Industrial Signature Interoperability Specification – MailTrusT (ISIS-MTT)
v1.1.
ISIS-MTT v1.1183 specifies fundamentals, standards and profiles for implementing security
concepts. This specification was the result of the merger of the Industrial Signature
Interoperability Specification (ISIS) and MailTrusT (MTT).
ISIS-MTT is a delta specification which is based on existing, relevant international standards
(S/MIME, PKIX, PKCS, X.509, ETSI, CEN ETSI) and which defines these in precise detail for use
in practical application. The specification focuses on conformance requirements which
must be fulfilled by compliant PKI components and applications during the generation and
processing of certain data objects, such as certificates.
The ISIS-MTT specification chiefly consists of a kernel document which is exclusively based
on the profiling (restriction of optional characteristics) of international standards and
which is hence expected to ensure interoperability on an international scale. This core
181 Refer to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter
II, module "Data-protection-compliant eGovernment"
183 Refer to http://www.isis-mtt.org/
94
SAGA 4.0
specification is mandatory for all manufacturers and suppliers and can be supplemented by
optional profiles as required. The "SigG Profiles" and "Optional Enhancements to the SigGProfile" already available describe the current status of qualified signatures in Germany.
The kernel document of the ISIS-MTT specification consists of eight parts with the following
contents:
1.
Establishing public-key certificates, attribute certificates and certificate revocation lists
2. Setting up and sending requests to the certification authority (PKCS#10) and replies
from the certification authority (PKCS#7)
3. Setting up encrypted and signed messages
4. Requests for public-key certificates, attribute certificates and certificate revocation lists
using LDAP, OCSP184, FTP or HTTP; setting up queries and responses to and from
timestamp units
5. Validity check for public key certificates and attribute certificates
6. Approved algorithms for hash functions, signatures, encryption, authentication of
messages to and from the certification authority; approved algorithms for XML
Signature and XML Encryption
7. Description of the "Cryptographic Token Interface" (PKCS#11) with data types and
functions
8. Profiling and expanding XML signatures and XML encryption
Mandatory: BSI, IT-Grundschutz-Kataloge [IT Baseline Protection Catalogues]
The BSI's IT-Grundschutz-Kataloge185 [IT Baseline Protection Catalogues] should be applied
and the standard security measures described there should be implemented. The use of
module, measure and risk catalogues supports a component-orientated work approach
with which IT security concepts can be implemented easily, efficiently and effectively.
Recommended: KoopA ADV, Handlungsleitfaden für die Einführung der
elektronischen Signatur und Verschlüsselung in der Verwaltung v1.1
[Guideline for the Introduction of the Electronic Signature and Encryption in the
Administration]
The Handlungsleitfaden für die Einführung der elektronischen Signatur und
Verschlüsselung in der Verwaltung [Guideline for the Introduction of the Electronic
Signature and Encryption in the Administration] issued by the KoopA ADV186 is designed to
facilitate solutions to cryptographic problems for selected projects in the public
administration, and is hence primarily devised as a working aid for public agencies. Typical
problems and tasks are defined in the form of scenarios for which potential solutions are
identified and described.
184 OCSP = Online Certificate Status Protocol
185 Refer to http://www.bsi.de/gshb/deutsch/
186 Refer to http://www.koopa.de/projekte/pki.html
SAGA 4.0
95
Recommended: BSI, E-Government-Handbuch [eGovernment manual]
The BSI E-Government-Handbuch187 [eGovernment manual] contains organizational and
technical recommendations concerning the use of IT in eGovernment applications. When
it comes to developing an eGovernment application within the meaning of SAGA, the
security-related recommendations contained in the manual are particularly relevant188.
The chapter on "IT und IT-Sicherheit" [IT and IT security] contains security
recommendations in the following modules:
1.
General information on secure eGovernment applications
2. Authentication in eGovernment
3. Optimization of web content retrieval
4. Secure integration of eGovernment applications
5. Secure payment methods for eGovernment
6. Secure communication in eGovernment
7. Secure client-server architectures for eGovernment
8. eGovernment without active content
The recommendations of the E-Government-Handbuch [eGovernment manual] should
always be taken into consideration especially when a protection requirement category is
"high" or "very high"189 – i.e. when the requirements for IT security go beyond the scope of IT
baseline security. The E-Government-Handbuch [eGovernment manual] provides
recommendations here for the design and implementation of a corresponding level of IT
security.
8.2
Process models
8.2.1
Technologies for process modelling
Mandatory: Role models and flow charts
Role models and flow charts should be used to define simple processes. All the roles and
systems related to a process must be identified, and the process steps must be described in
the form of flow charts. In a broader sense, flow charts should be orientated towards DIN
66001: "Informationsverarbeitung, Sinnbilder und ihre Anwendung" [Information
processing, symbols and their use].
187 Refer to http://www.bsi.bund.de/fachthem/egov/3.htm
188 Refer to http://www.bsi.bund.de/fachthem/egov/6.htm#Kapitel_IV, sub-chapter IV B: "IT
and IT security"
189 Refer to section 8.1 "IT security concept" on page 91
96
SAGA 4.0
Mandatory: Unified Modeling Language (UML) v. 2.0
The Unified Modeling Language (UML)190 should be used for object-orientated modelling in
the preparation and documentation of large projects. Use cases and activity diagrams are a
particularly tried-and-tested way of creating and co-ordinating transparent specifications.
These specifications can be reused with the respective tools.
8.2.2 Interchange formats for process models
Recommended: XML Metadata Interchange (XMI) v2.x
XML Metadata Interchange (XMI)191 is a standard of the Object Management Group (OMG)
which should be used in XML for the notation and interchange of Meta Object Facility
(MOF)-based models (example: UML). This format is open and manufacturer-independent.
UML 2.0192 can be transformed to XMI 2.0 and XMI 2.1. XMI v2.0.1 was standardized as ISO/IEC
19503:2005193 .
8.3
Data models
8.3.1
Technologies for data modelling
Mandatory: Entity Relationship Diagram (ERD)
Entity Relationship Diagrams should be used when developing relational database
schemas. Functional data models for a special rough concept should also be presented
using ER diagrams.
Mandatory: Unified Modeling Language (UML) v. 2.0
UML should be used in data modelling for object-orientated applications. Class diagrams,
for instance, are the approach of choice and can also be used in other applications or by
other tools. XML data structures can be directly generated from the corresponding
specifications.
8.3.2 Interchange formats for data models
Mandatory: XML Schema Definition (XSD) v1.0
XML schemas according to the World Wide Web Consortium (W3C)194 should be generated
using the XML Schema Definition (XSD) for the structured description of data.
190
191
192
193
194
Refer to http://www.uml.org/
Refer to http://omg.org/technology/documents/formal/xmi.htm
Refer to section 8.2.1 "Technologies for process modelling" on page 95
Refer to http://www.iso.org/
Refer to http://www.w3.org/XML/Schema
SAGA 4.0
97
Recommended: Regular Language Description for XML New Generation (Relax NG)
The ISO standard (ISO/IEC 19757-2:2003195) Relax NG196 can, just like the XML Schema Defini
tion (XSD), be used for the structured description of data.
Relax NG is less widespread than XSD and has less tool support. However, it is simpler, easier
to read and yet more expressive.
Although XSD is mandatory for the structured description of data, the use of Relax NG is still
possible because Relax-NG schemas can be transformed to XML schemas using (Open
Source) tools197.
Recommended: XML Metadata Interchange (XMI) v2.x
Analogous to section 8.2.2 "Interchange formats for process models" on page 96.
8.3.3 Description language for metadata of files
Recommended: Resource Description Framework (RDF)
Resource Description Framework (RDF)198 is a language for presenting information about
resources on the web that was developed by W3C. RDF is designed to describe metadata
and ontologies and hence forms an important part of Semantic Web. RDF makes it possible
to declare vocabulary, i.e. to define terms, so that the relevant information about resources
is described in such a manner that it can be gathered, integrated and reused. Simple
vocabulary, such as Dublin Core, can also be used in RDF. RDF should be used to describe
metadata for web resources.
Recommended: Dublin Core (DC)
Dublin Core (DCMI Metadata Terms)199 is a widely used standard which was standardized by
ISO200 and NISO201. The standard is a development of the Dublin Core Metadata Initiative
(DCMI). The latest version was standardized by NISO in May 2007 – the revision is still based
on the ISO 15836-2003 standard from February 2003. This standard should be used for the
metadata description of websites, digital objects and documents.
The second chapter of the specification ("The Dublin Core Metadata Element Set") contains
the 15 core elements of the standard: contributor, coverage, creator, date, description,
format, identifier, language, publisher, relation, rights, source, subject, title and type. Each
element corresponds to a property and a certain value can be assigned to each property.
They are optional and can be used as often as required to describe an object. Other sub195
196
197
198
199
200
201
Refer to http://www.relaxng.org/
Refer to http://www.thaiopensource.com/relaxng/trang.html
Refer to http://www.w3.org/TR/rdf-primer/
Refer to http://dublincore.org/documents/dcmi-terms/
Published as ISO 15836:2003, refer to http://www.iso.org/
Published as ANSI/NISO Z39.85 - 2007, refer to http://www.niso.org/standards/index.html
98
SAGA 4.0
elements – called "refinements" or "qualifiers" – are available for certain elements, and
enable a more precise description of resources.
The elements of Dublin Core can be used in HTML/XHTML and RDF/XML documents. In
HTML documents, Dublin-Core metadata can be stated with the META element in the
document header.
8.4
Application architecture
This section defines programming languages and technologies for implementing the
application architecture. The first part defines standards for the middleware of the
eGovernment architecture module with special emphasis on the aspect of application
integration. This is followed by an extension of the standards to cover applications without
middleware or with a low middleware share, respectively, so that the middleware standards
can also be used for simpler applications.
The specifications and recommendations are based on the design principles of operatingsystem neutrality, interoperability and portability.
Middleware services – such as replication, distributed transaction management,
personalization, internationalization, messaging, etc. – are referenced in the current
version to a certain extent.
Deviations from preferred technologies (i.e. mandatory, recommended technologies) are
acceptable in justified cases, for example, in the case of significant economic advantages.
8.4.1
Application architecture with middleware
Mandatory: Java Platform, Enterprise Edition (Java EE) v5
Technologies of the Java Platform, Enterprise Edition (JavaEE)202 should be used to develop
and integrate the following applications (integrated applications) on the middle tier:
a. one-for-all offers (OFA offers)203,
b. applications which directly integrate basic components or libraries provided for this
purpose, and
c. applications designed, as a whole or in part (components), for re-use (porting).
Java EE is a specification which defines several programming interfaces and a development
process. Java EE in its entirety constitutes an architecture that considers and supports major
aspects of business-critical applications. Java EE already offers important function modules
which can be used to develop applications. Since version 1.4204, these also include standard
programming interfaces (APIs) and technologies as so-called core libraries: Java
Authentication and Authorization Service (JAAS), Java API for XML Parsing (JAXP) and Java
Naming and Directory Interface (JNDI). All the core libraries should be given preference
over alternative technologies.
202 Refer to http://java.sun.com/javase/
204 Published as JSR-000151, refer to http://www.jcp.org/en/jsr/detail?id=151
SAGA 4.0
99
The difference between Java EE v5205, which was finalized in May 2006, and its predecessor
J2EE v1.4 can be found especially in the upgrading capacity of applications and the
simplification of the programming model. Enhancements were also made, for instance, to
the definition and use of web services and the mapping of Java classes to XML and
databases.
Compared to Java SE v5, Java EE v5 offers the following APIs and technologies as so-called
optional libraries:
a. Java Message Service (JMS) v1.1
b. J2EE Connector Architecture (JCA) v1.5
c. Java Transaction API (JTA),
d. JavaMail API v1.4,
e. Java Management Extensions (JMX) v1.2,
f.
Enterprise JavaBeans (EJB) v3.0206,
g. Java Server Faces (JSF) v1.2207,
h. Java Server Pages (JSP) v2.1, and
i.
Java Servlet API v2.5.
Thanks to the Java Community Process208, more and more application-near elements will
increase the diversity of Java EE in the near future. New elements are defined via so-called
Java Specification Requests (JSR).
Mandatory: Java Platform, Standard Edition (Java SE) v5
If an application does not require full Java EE functionality, neither initially nor on a
permanent basis, Java EE technologies should be used individually as an alternative
solution. The basis for this is the Java 2 platform as the Standard Edition (Java SE)209. The
individual technologies should be used in accordance with Java EE specification 5210 in
order to create a compatible migration path to Java EE.
Under observation: C# Language Specification/ Common Language Infrastructure
(CLI)
The ECMA-334211 "C# Language Specification" standard (ISO/IEC 23270:2006212) specifies the
form and the interpretation of programmes which were written in C# language.
205 Published as JSR-000244, refer to http://www.jcp.org/en/jsr/detail?id=244 and
http://java.sun.com/javaee/
206 Instead of using EJB, another application framework can also be used, such as the Spring
Application Framework, refer to http://www.springframework.org/
208 Refer to http://www.jcp.org/
209 Refer to http://java.sun.com/javase/
211 Refer to http://www.ecma-international.org/publications/standards/Ecma-334.htm
100
SAGA 4.0
The ECMA-335213 "Common Language Infrastructure (CLI)" standard (ISO/IEC 23271:2006
and ISO/IEC TR 23272:2006214) defines an infrastructure for different system environments in
which applications can be executed which were written in different programming
languages. The infrastructure abstracts from specific properties of the system
environments so that applications do not have to be changed in order to run them on
different systems.
There are two implementations of the ECMA standard. .NET-Framework from Microsoft
runs under Windows only. The two ECMA standards are based on .NET v2.0 and are hence
also part of .NET v3.0. A further implementation, called Mono215, ensures availability for
further operating systems.
The two ECMA standards do not form a complete development framework because they do
not support, for instance, the implementation of clients and presentation layers.
Under observation: Business Process Execution Language for Web Services (BPEL4WS)
v1.1
BPEL4WS216 can be used to compose business processes on the basis of web services.
BPEL4WS, which is under the patronage of OASIS, is an XML-based description language
which supplements web services and the related standards (SOAP, WSDL, UDDI) with
business transactions.
Major infrastructure and application suppliers support the specification. Furthermore,
tools, including Open-Source solution217, are provided. BPEL4WS was developed further to
the OASIS standard WS-BPEL 2.0.
Under observation: Web Services Business Process Execution Language (WS-BPEL) v2.0
WS-BPEL218 v2.0 was adopted by OASIS in April 2007 as the standard. The standard is used to
compose business processed based on web services. Tools for WS-BPEL v2.0 are
commercially available. WS-BPEL v2.0 is not compatible with its predecessor BPEL4WS v1.1.
8.4.2 Application architecture without middleware
In addition to the standards discussed in the previous section, the following technology is
also available for simple eGovernment applications without middleware.
Recommended: PHP Hypertext Preprocessor (PHP) v5.x
PHP219 (recursive acronym for "PHP: Hypertext Preprocessor") can be used for applications
without an integration requirement, i.e. non-distributed, stand-alone applications which
213
214
215
216
217
218
219
Refer to http://www.ecma-international.org/publications/standards/Ecma-335.htm
Refer to http://www.mono-project.de/
Refer to http://www-128.ibm.com/developerworks/library/specification/ws-bpel/
Refer to http://www.bpelsource.com/products/
Refer to http://www.oasis-open.org/specs/index.php#wsbpelv2.0
Refer to http://www.php.net/
SAGA 4.0
101
do not communicate with one-for-all offers (OFA offers)220 with legacy systems or with other
eGovernment special applications. PHP is developed as an open-source project by the PHP
Group and represents a script language embedded in HTML for developing web
applications.
Version 5 features comprehensive support for object-orientated programming concepts.
Procedures for data encapsulation, referencing of variables and exception handling mark
important progress within the scope of further development.
8.5
Client
The client is a software on a terminal device which makes use of a service offered by
middleware. The client tier includes both the classical user site with all the options state-ofthe-art technology has to offer in order to interact with public administrations, with access
to information possible via different media. In Germany, the following media are currently
the most popular, so that optimum conditions for the widespread use of eGovernment
applications will exist if the information on offer is tailored to these devices:
a. Computers (PCs, notebooks)
b. Mobile phones / personal digital assistants (PDAs)
c. External systems (e.g. ERP systems of industrial companies)
Standardization efforts for game consoles and, in particular, for digital interactive TV have
not yet resulted in uniform recommendations. The so-called "thin client" seems to be the
most promising device in terms of public acceptance. Thin clients come with very lowprofile hardware and software and require the server to provide as much functionality as
possible.
8.5.1
Access to information with computers
Two different clients are generally available on computers221 in order to access or receive
information: web browser and specific client applications (e.g. Java clients, also Applets).
The latter, for instance, permit direct access to Internet-based services, e-mail servers and –
depending on authorization – to the operating system in order to use local resources, such
as local data volumes. Whenever active contents are used, no client technologies other
than those permitted in SAGA may be used. The use of Active-X-Controls is generally not
permitted. When active contents are used, a parallel offer without active contents should
also be available, if possible; refer also to section 1.5 "Basic principles for eGovernment
applications" on page 13.
221 A device is referred to as a computer in this context if the device does not have a small
display, has no low bandwidth and has a keyboard.
102
SAGA 4.0
Mandatory: Java Network Launching Protocol (JNLP) v1.5
Java client applications should be delivered via the Internet using the Java Network
Launching Protocol (JNLP)222. In this case, the "Java Web Start"223 reference implementation
can be used.
The use of JNLP enables the simple, platform-independent distribution of Java applications
and avoids version conflicts with Java Runtime Environments (JREs).
8.5.1.1
Web browsers
In order to enable wide-spread use of the eGovernment applications on offer, web browsers
should be used as the front-end device and these should be capable of processing and
presenting the presentation-tier formats (refer to section 8.6). The following browser-based
client technologies are permitted in this context:
a. The use of cookies is permitted on condition that
i.
these are not persistent, and
ii.
websites of a domain do not include contents of other domains which set
cookies.
The recommendations for the HTTP protocol according to section 8.7.5 must be taken
into consideration in this context.
b. The use of Javascript is permitted, however, it must be ensured that the websites can still
be used even if Javascript was deactivated. This demand corresponds to BITV224 which is
classified as mandatory. This ensures that the user is not forced to lower his/her security
settings due to eGovernment applications. Section 8.6.4 "Active contents" on page 108
must be taken into consideration when Javascript is used.
c. The use of Java Applets is permitted if these are signed by the server and can hence be
identified by the client as authentic and non-corrupted. Manufacturers of Java Applets
must subject their products to quality assurance, preferably by an independent
software company, or must at least warrant the quality of their products in a
declaration of quality.225
d. Plug-ins are used exclusively according to the requirements listed on the website:
http://www.kbst.bund.de/saga-plugins.
e. Configuration examples are prepared for customary browser types and made available
by BSI on the Internet.
f.
The confidentiality of form data must be ensured by the use of TLS-encrypted channels
and the pertinent server certificates.
222 Published as JSR-000056 (Final Release), refer to http://www.jcp.org/en/jsr/detail?id=56
223 Refer to http://java.sun.com/products/javawebstart/
224 Refer to BITV, section 6.3 "It must be ensured that documents created using markup
languages can be used if scripts, applets or other programmed objects are deactivated."
(http://bundesrecht.juris.de/bitv/)
225 Further information on this subject can be found on the web at:
http://www.kbst.bund.de/saga-applets.
SAGA 4.0
103
g. The statutory instrument (ordinance) on barrier-freedom remains fully applicable to
the use of permitted client technologies.
8.5.1.2
Client applications
The web browser is the standard client for applications with direct access to web servers.
Client applications can be used if direct access to Internet-based services is not necessary, or
if the functionality of a web browser must be reasonably seen to be inadequate, for
example, in the case of complex business transactions with direct file system access or use of
legacy software. These applications are installed on the client computer and must be
updated as required by technical progress. Updates can be made available on CD-ROM or as
signed applications for downloading226 from a website. The use of Java applications is
recommended (advantage: platform independence).
Client applications must meet with the following requirements:
a. Any personal and security-critical data is stored in encrypted form on the local data
medium.
b. In the case of direct access to Internet-based services, secure data transmission to the
server is supported, refer to section 8.7.5 "Application protocols" on page 126. No
protocols other than those defined in section 8.7.1 "Middleware communication" on
page 121 are permitted for other client/server communications.
c. The formats documented in SAGA for exchanging user data with other applications
should be supported.
d. A manufacturer-independent software company assures the quality of the application.
e. The application is supplied along with a software certificate which is verified during the
course of the installation.
f.
Besides an option to download the application from the Internet, distribution on CDROM is also offered.
g. The statutory instrument (ordinance) on barrier-freedom must be taken into
consideration.
8.5.1.3
E-mail client
The e-mail clients used to receive, send and process e-mails must at least ensure technical
support for the e-mail standards referred to in section 8.7.3 "E-mail communication". Note
that communication of these clients is standardized with regard to communication with
public administrations only and/or restricted to the above. With regard to the use of
external mail servers not connected to federal institutions, the client is not subject to any
restrictions whatsoever in terms of the standards and protocols used.
8.5.2 Access to information with mobile devices
Contrary to the computer, mobile phones, PDAs and other mobile devices feature either
226 Refer also to "Java Network Launching Protocol (JNLP) v1.5" on page 102
104
SAGA 4.0
a. a small display,
b. low bandwidth, or
c. no standard keyboard
and must support the standards offered by servers for mobile devices of the presentation
tier227. Furthermore, the standards, which are generally described for the presentation of
contents by computers, should also be fulfilled as comprehensively as possible by the
mobile devices228.
The requirements concerning active contents described in section 8.5.1 "Access to
information with computers" on page 101 must be observed.
8.5.3 Access to information via external systems
Communication and interaction between external and internal systems should be handled
via a subset of the standards defined for communication and interaction between internal
systems. In this respect, XML via SOAP is considered to be equivalent to RMI with regard to
server-to-server communication229.
8.5.4 Technologies for authentication
In order to ensure that the protection aims of confidentiality and integrity are achieved,
certain eGovernment applications require the identification and authentication of
communication partners.
Mandatory: BSI, E-Government-Handbuch, module: "Authentisierung im
eGovernment" [eGovernment manual, module: Authentication in
eGovernment]
Different authentication mechanisms can be adopted in this context, e.g. user
identification / password, PIN / TAN or certificates. The "Authentisierung im
eGovernment"230 [Authentication in eGovernment] module of the E-GovernmentHandbuch [eGovernment manual] issued by BSI addresses different authentication
methods with a view to aspects of technical security.
Recommended: Security Assertion Markup Language (SAML) v2.0
SAML231 is an XML-based format for exchanging authentication information. The exchange
of data in a uniform format especially supports interoperability between eGovernment
applications. Version 2.0 was published in March 2005.
227 Refer to section 8.6.13 "Technologies for presentation on mobile devices" on page 119
228 Refer to section 8.6 "Presentation" on page 105
229 Refer to section 8.6.6 "Interchange formats for data " on page 109, section 8.4 "Application
architecture" on page 98, section 8.7 "Communication" on page 121 and section 8.8
"Backend" on page 130
230 Refer to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter
IV B, module "Authentication in eGovernment"
231 Refer to http://www.oasis-open.org/specs/index.php#samlv2.0
SAGA 4.0
105
Under observation: Kerberos v5
Kerberos232 is a protocol for authentication in computer networks that was developed by
the Massachusetts Institute of Technology (MIT). Interoperability is supported through the
uniform exchange of authentication data. However, operating-system dependent
expansions do sometimes lead to incompatibilities between different implementations.
8.6 Presentation
The presentation tier provides information to the clients. Depending on the given
application, different formats must be made available. These are listed in the following
sections. The use of open interchange formats which offer a sufficient number of functions
and which are available on different platforms is generally required.
It is permitted to offer the information in addition - or, if so agreed to by all the parties
involved, even as an alternative - to the mandatory and recommended formats using
formats not considered within the scope of SAGA.
8.6.1
Barrier-free presentation
Mandatory: Barrierefreie Informationstechnik Verordnung (BITV)
[Barrier-free information technology ordinance]
In order to make the Internet accessible as a source of information to disabled people too,
the avoidance of barriers for people with disabilities is requested. In order to ensure this
kind of barrier-free presentation, the requirements of the "Verordnung zur Schaffung
barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz
(Barrierefreie Informationstechnik Verordnung – BITV)"233 [Ordinance on the creation of
barrier-free information technology pursuant to the law on equal opportunities for the
disabled (barrier-free information technology ordinance – BITV)] are to be adhered to. This
statutory instrument implements section 11 of the "Behindertengleichstellungsgesetz"
[Equal Opportunities for Individuals with Disabilities Act] and, in particular, considers the
Web Content Accessibility Guidelines234 of W3C, version 1.0. Concerning the barrier
freedom issue, refer also to section 5.4.3 on page 62.
232 Published as RFC 1510, refer to http://www.ietf.org/rfc/rfc1510.txt und
http://web.mit.edu/kerberos/
233 Refer to http://bundesrecht.juris.de/bitv/
234 Refer to http://www.w3.org/TR/WCAG10/
106
SAGA 4.0
8.6.2 Character sets
Mandatory: Unicode v4.x UTF-8
In order to provide a sufficient number of characters for the different letters, numbers and
symbols used world-wide, the character set used for documents should be ISO 10646:2003235
(also known as Unicode v4.x) in UTF-8 encoding236.
Recommended: Unicode v4.x UTF-16
If documents are written in a non-west European language (e.g. Greek, Bulgarian), ISO
10646:2003237, also known as Unicode v4.x, in UTF-16 encoding238 can be used.
8.6.3 Technologies for information processing
Mandatory: Hypertext Markup Language (HTML) v4.01
HTML is the established language for publishing hypertext on the World Wide Web. In
addition to the text, multimedia and hyperlink functions of earlier HTML versions, HTML
v4.01239 supports more multimedia options, script languages and improved forms and print
functions. The use of HTML v4.01 is necessary for the technical implementation of barrierfree access in line with the Web Content Accessibility Guidelines, version 1.0. The
separation of the document structure and presentation has been improved. In this respect,
the use of stylesheets instead of HTML presentation elements and attributes is actively
encouraged. HTML 4 is also making great progress with regard to the internationalization
of documents in an effort to make the World Wide Web truly world-wide.
Mandatory: Multipurpose Internet Mail Extensions (MIME) v1.0
The Multipurpose Internet Mail Extensions (MIME) format should be used for the
standardized definition of the format of a file or any part thereof. It enables the e-mail client
or the web browser to unambiguously identify the file type, refer to RFC 2045 to RFC
2049240. The official list of possible manifestations of MIME types can be found at the
Internet Assigned Numbers Authority (IANA)241.
235
236
237
238
239
This specification is available at http://www.unicode.org/
This specification is available at http://www.unicode.org/.
Refer to http://www.w3.org/TR/html401/, standardized as ISO/IEC 15445:2000, refer to
http://www.iso.org/
240 Refer to http://www.ietf.org/rfc.html
241 Refer to http://www.iana.org/assignments/media-types/
SAGA 4.0
107
Mandatory: Java Servlet v2.5
Servlet v2.5242 should be used for the dynamic generation of web contents. Servlet v2.5
makes it possible for application servers to accept and send a dynamic response to client
queries on the basis of Java EE 5.
Mandatory: Java Server Pages (JSP) v2.1
JSP v2.1243 should be used for the dynamic, server-based generation of web contents. JSP v2.1
contains an Expression Language (EL) which is used to separate the Java Code from the JSP
Code and to embed it in statistical fragments (e.g. HTML). JSP v2.1 is based on Java Servlet
v2.5 technology.
Recommended: Extensible Hypertext Markup Language (XHTML) v1.0
XHTML v1.0 Second Edition, a W3C recommendation244 from August 2002, is an exchange
format (reformulation of HTML v4.0 whilst maintaining conformance to XML) which meets
with a host of requirements concerning interoperability and barrier freedom. The use of
XHTML v1.0 speeds up the development of websites because, in contrast to HTML v4.01,
many previously required browser optimizations are no longer necessary. Furthermore,
clear, syntactical specifications (lower case for elements and attributes, well-formed
according to XML) significantly boost the readability of the source code and hence the cost
of its maintenance and further development. XHTML 1.0 is supported by all customary
browsers.
Recommended: Cascading Style Sheets Language Level 2 (CSS2)
Cascading Style Sheets Language Level 2 (CSS2)245 should be used to design HTML pages.
Recommended: Extensible Stylesheet Language (XSL) v1.0
Extensible Stylesheet Language (XSL)246, version 1.0, should be used for the server-based,
dynamic transformation and presentation of XML documents, for instance, in HTML files.
Recommended: Extensible Stylesheet Language Transformations (XSLT) v1.0
If applications use different XML schemas, conversion from one format to another can
become necessary for data interchanging purposes. This format conversion operation
should be carried out using the XSLT247 language defined by W3C as part of XSL (Extensible
Stylesheet Language).
242 Published as JSR-000154 (Maintenance Release), refer to http://www.jcp.org/en/jsr/detail?
id=154
244 Refer to http://www.w3c.org/TR/xhtml1
245 Refer to http://www.w3.org/TR/REC-CSS2/
246 Refer to http://www.w3.org/TR/xsl/
247 Refer to http://www.w3.org/TR/xslt
108
SAGA 4.0
Under observation: Extensible Stylesheet Language (XSL) v1.1
XSL v1.1 has been a W3C recommendation since 5 December 2006248. A number of new
features were introduced with this version, for instance, the referencing of page numbers,
bookmarks as well as change marks. Compared to its predecessor version, XSL v1.0, tool
support and the relevance of the practical application of the standard are not as advanced.
Under observation: Extensible Stylesheet Language Transformations (XSLT) v2.0
Extensible Stylesheet Language v2.0 was adopted in January 2007 as a W3C
recommendation249. It offers many new features, such as the use of XPath 2.0. Other
enhancements include the output methods, as well as sorting and grouping options.
XSLT v2.0 does not come with full downward compatibility. Moreover, few processors are
available up to now.
8.6.4 Active contents
Active contents are computer programs which are contained on websites (e.g. JavaScript)
or which are automatically reloaded when a page is viewed (e.g. Java Applets, ActiveX
Controls or flash animations) and which are executed on the client (by the browser or by the
operating system). When active contents are used, the restrictions described in section 8.5
must be taken into consideration.
Mandatory: ECMAScript Language Specification
In as far as Javascript is used within HTML pages according to section 8.5.1.1 "Web browsers"
on page 102, this must conform to the ECMA-262 specification, 3rd Edition250 dated
December 1999. This specification was also adopted by ISO/IEC as a standard under the
name ISO/IEC 16262251.
8.6.5 Forms
Under observation: XForms v1.0
XForms is a specification252 for web forms. The aim of this specification is to replace the
forms implemented in HTML or XHTML. XForms offers a wider range of functions and in the
case of client-end processing leads to a reduction in the amount of server access.
Although implementations and also plug-ins are available, not all browsers support XForms
by default.
248
249
250
251
252
Refer to http://www.w3.org/TR/xsl11/
Refer to http://www.w3c.org/TR/xslt20/
Refer to http://www.ecma-international.org/publications/standards/Ecma-262.htm
Refer to http://www.w3.org/TR/xforms/
SAGA 4.0
109
8.6.6 Interchange formats for data
Mandatory: Extensible Markup Language (XML) v1.0
XML v1.0253 is a language derived from the Standard Generalized Markup Language (SGML)
which should be used for structured data description. The language enables extension and
the addition of tags. The data shown is presented in Extensible Stylesheet Language (XSL)254.
XML should serve as the universal and primary standard for the interchange of data
between all the information systems relevant for administrative purposes.
New systems to be installed should be capable of exchanging data using XML. Existing
systems do not necessarily have to be XML-enabled, however, they should aim to be able to
exchange XML data using adapters (integration components).
Under observation: Election Markup Language (EML) v4.0
Standard Election Markup Language (EML)255 can be used especially in order to exchange
data in the environment of eVoting processes.
EML v4.0 was adopted in February 2006 as the OASIS standard. This language defines a
series of XML schemas which are suitable and which implement a generic election process.
These election processes can include public elections (general elections, municipal
elections) or private elections (works council elections, secret ballots). EML can be adapted
to all scenarios and also supplies security functions for data backup.
Under observation: Extensible Markup Language (XML) v1.1
XML v1.1256 is a revised version of XML v1.0 and was published on 4 February 2004 in
"Recommended" status and amended on 15 April 2004. Its Unicode capabilities have been
improved and inconsistencies in line end markings have been eliminated. There are
currently almost no parsers for XML v1.1.
8.6.7 Exchange formats for documents
8.6.7.1
Formats for text documents for exchanging information
Text documents used to exchange information should only be read by the target group and
should not be changed. This is why no further editing is foreseen.
253
254
255
256
Refer to http://www.w3.org/XML/
Refer to "Extensible Stylesheet Language (XSL) v1.0" on page 107
Refer to http://www.oasis-open.org/specs/index.php#eml4.0
Refer to http://www.w3.org/TR/xml11/
110
SAGA 4.0
Mandatory: Portable Document Format (PDF) v1.4
Adobe's platform-independent Portable Document Format should be used for text
documents where no further editing is foreseen and to support forms and barrier-free text
documents. PDF version 1.4257 is supported by Acrobat Reader258 , version 5 and higher.
If this format is used, the recommendations of the "Sicherer Internet-Auftritt im
E-Government" [Secure Internet Presence] module of the eGovernment manual must be
considered with regard to active content259. Especially when it comes to converting
(partially) blackened text to PDF format, it must be ensured that the text can in fact no
longer be copied / searched for in PDF. Similarly, the PDF password function, irrespective of
the key strength of encoding, is not a sufficient security measure for documents with
content that needs to be protected, because this function can be bypassed using the
appropriate tools.
Mandatory: Hypertext Markup Language (HTML)
Hypertext documents used to exchange information, e.g. newsletters, should be used in
HTML260 format, refer to section 8.6.3 "Technologies for information processing" on page
106.
Recommended: Portable Document Format (PDF) v1.5
PDF version 1.5261 is the successor to PDF v1.4, which was classified as "Mandatory". For older
versions of Windows and MacOS, there are at times no distributions of Acrobat Reader for
PDF v1.5 available. PDF version 1.5 is supported by Acrobat Reader262, version 6 and higher.
This version also features extensions in the areas of cryptography, compression and
content-related tagging. If this format is used, the recommendations of the "Sicherer
Internet-Auftritt im E-Government" [Secure Internet Presence] module of the eGovernment
manual must be considered with regard to active contents263.
Under observation: Portable Document Format (PDF) v1.6
PDF version 1.6264 is currently used to a very limited extent only. This version is the successor
to version 1.4, which was classified as "Mandatory" and to version 1.5, which was classified as
"Recommended". It features enhancements in the areas of cryptography and the
embedding of file attachments. PDF version 1.6 is supported by Acrobat Reader265, version 7
and higher. If this format is used, the recommendations of the "Sicherer Internet-Auftritt im
257
258
259
260
261
262
263
264
265
Refer to http://www.adobe.com/devnet/pdf/pdfs/PDFReference.pdf
Refer to http://www.adobe.de/products/acrobat/readermain.html
Refer to http://www.bsi.bund.de/fachthem/egov/download/4_IntAuf.pdf
Standardized as ISO/IEC 15445:2000, refer to http://www.iso.org/
Refer to http://www.adobe.com/devnet/pdf/pdfs/PDFReference15_v6.pdf
Refer to http://www.bsi.bund.de/fachthem/egov/download/4_IntAuf.pdf
Refer to http://www.adobe.com/devnet/pdf/pdfs/PDFReference16.pdf
SAGA 4.0
111
E-Government" [Secure Internet Presence] module of the eGovernment manual must be
considered with regard to active contents266.
8.6.7.2
Formats for text documents for further processing
It must be possible to edit text documents which are foreseen for further processing. A
distinction is made between simple text documents and complex text documents
containing layout information.
Mandatory: Text
Simple, mostly non-structure text documents which are foreseen for further processing and
which have no layout requirements should be exchanged in the widely used text format
(e.g. with the .txt file extension) in order to ensure that these are generally readable. The
character sets to be used are laid down in section 8.6.2.
Recommended: Open Document Format for Office Applications (OpenDocument) v1.0
OpenDocument267 was standardized by OASIS as an XML-based document format for texts,
spreadsheets, presentations and other Office documents. The contents of the document are
separate from the information about its layout and can be processed independent of each
other. OpenDocument can be used to exchange complex documents that are foreseen for
further processing. In November 2006, OpenDocument v1.0 was published as a standard
under the name ISO/IEC 26300:2006268. OpenDocument is supported, for instance, by the
platform-independent, license-free and open Office package from OpenOffice.org269.
Under observation: Office Open XML (OOXML)
As an XML-based document format for texts, spreadsheets, presentations and other Office
documents, Office Open XML270 was published by ECMA in December 2007 as the ECMA-376
standard. It can be used to exchange complex documents which are to be processed
further.
8.6.7.3
Formats for spreadsheets for exchanging information
Spreadsheets used to exchange information should only be read by the target group and
Analogous to section 8.6.7.1 on page 109.
266 Refer to http://www.bsi.bund.de/fachthem/egov/download/4_IntAuf.pdf
267 Refer to http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0os.pdf
269 Refer to http://de.openoffice.org/
270 Refer to http://www.ecma-international.org/publications/standards/Ecma-376.htm
112
SAGA 4.0
8.6.7.4
Formats for spreadsheets for further processing
It must be possible to edit spreadsheets which are foreseen for further processing. A
distinction is made between simply structured data and complex documents, even with
layout information.
Mandatory: Comma Separated Value (CSV)
Tables with simple structure data without layout requirements should be exchanged using
Comma Separated Values271 (file extension: .csv).
Under observation: Open Document Format for Office Applications (OpenDocument)
v1.0
Refer to section 8.6.7.2 on page 111. OpenDocument272 supports the referencing of formula
languages, however, these do not form part of the standard. An OASIS Technical Committee
is working on a suitable specification273.
8.6.7.5
Formats for presentations for exchanging information
Presentations used to exchange information should only be read by the target group and
271 Published as RFC 4810, refer to http://www.ietf.org/rfc/rfc4180.txt
272 Standardized as ISO/IEC 26300:2006, refer to http://www.iso.org/
273 Refer to http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office-formula
SAGA 4.0
113
Mandatory: Hypertext Markup Language (HTML)
Presentations that cannot be changed which are available in hypertext document format
should be exchanged in HTML274 format, refer to section 8.6.3 "Technologies for
information processing" on page 106.
Under observation: Synchronized Multimedia Integration Language (SMIL) v2.0
SMIL is an XML-based, standardized language for writing interactive multimedia
presentations275. "A typical example of such an application is a multimedia news centre
which plays audios and videos to a message whilst background information is displayed at
the same time on HTML websites."276
There is a host of free SMIL players. Of the browsers currently available on the market, up to
now only the Internet Explorer supports a subset of SMIL277.
8.6.7.6
Formats for presentations for further processing
It must be possible to edit presentations which are foreseen for further processing.
Under observation: Open Document Format for Office Applications (OpenDocument)
v1.0
8.6.7.7
Secured document exchange
The "communication" interaction stage requires the exchange of secure documents. This
includes, for example, securing documents as e-mail attachments as well as securing
documents for all kinds of communication paths.
274 Standardized as ISO 15445:2000, refer to http://www.iso.org/
275 Refer to http://www.w3.org/TR/2005/REC-SMIL2-20050107/
276 Refer to Pauen, Peter: Zukunftsorientierte Ansätze – SMIL [Future-orientated approaches –
SMIL] http://www.informatik.fernuni-hagen.de/pi3/PDFs/SMIL.pdf
277 Refer to http://www.w3.org/AudioVideo/#SMIL
114
SAGA 4.0
The ISIS-MTT v1.1 standard is relevant with regard to securing e-mail attachments whilst
XML Signature and XML Encryption as XML-specific standards are relevant for the secure
exchange of XML documents (e.g. for forms designed for further processing).
Mandatory: Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT)
v1.1., Part 3
ISIS-MTT v1.1 defines an interoperable data interchange format for signed and encrypted
data. It also considers the securing of binary data (in particular, Part 3: Message Formats), so
that secured transmission of all kinds of files as e-mail attachments is possible.
Mandatory: XML Signature
The joint W3C and IETF standard XML Signature (XML Signature Syntax and Processing,
W3C Recommendation and IETF RFC 3275)278 describes digital signatures for all kinds of
data (however, usually XML) by providing an XML schema and a set of processing rules (for
generating and validating the signature). The signature can cover one or more documents
and/or different kinds of data (pictures, text, etc.).
One central feature of XML Signature is that it is possible to sign specific parts of an XML
document only rather than the entire document. Thanks to this flexibility, it is, for example,
possible to secure the integrity of certain elements of an XML document whilst other parts
can be edited. For instance, a user can fill in certain parts of a signed XML form without
violating the integrity of the document. This was not possible with conventional signatures
because the complete document was always signed, so that any change / addition would
have meant a violation of its integrity.
Mandatory: XML Encryption
The W3C standard XML Encryption (XML Encryption Syntax and Processing, W3C Recom
mendation)279 provides an XML schema and a set of processing rules which support the
encryption/decryption of entire documents, including XML documents, XML elements and
contents of XML elements.
Together with XML Signature, XML Encryption is the foundation for several standards
accepted in the industry for secure XML-based document exchange (Web Services Security,
SAML, ISIS MTT, ebXML-Messaging, FinTS, OSCI-Transport).
Under observation: XML Advanced Electronic Signatures (XAdES) v1.2
The "XML Advanced Electronic Signatures (XAdES)"280 standard was developed by the
European Telecommunications Standard Institute (ETSI). XAdES signatures not only fulfil
the requirements of the advanced electronic signature under the EU Directive, they also
warrant additional non-repudiation and long-term validity. XAdES is an extension of XML
Signature.
278 Refer to http://www.w3.org/TR/xmldsig-core/
279 Refer to http://www.w3.org/TR/xmlenc-core/
280 Refer to http://www.w3.org/TR/XAdES/
SAGA 4.0
115
In Germany, XAdES is used, for instance, by Deutsche Post's Signtrust. There are several
commercial suppliers of programs which process documents for storage on the basis of
XAdES.
8.6.8 Interchange formats for graphics
Mandatory: Graphics Interchange Format (GIF) v89a
In view of its widespread use, Graphics Interchange Format (GIF)281 should be used to
exchange graphics and diagrams. GIF graphic files are compressed with a colour depth of
256 colours (8 bits per pixel.
Mandatory: Joint Photographic Experts Group (JPEG)
The Joint Photographic Experts Group282 (JPEG) format should be used to exchange
photographs. This format supports changes in the compression factor and the definition of
density, so that a compromise between file size, quality and use is facilitated. JPEG can be
used to store colour and grey-value images with 16.7 million colours (24-bit colour
information). This format is supported by a host of graphic and presentation programs.
Conventional compression in JPEG results in losses, however, it does achieve high
compression rates. JPEG is not suitable for graphics with similar colour surfaces and
strongly contrasting colour transitions (example: characters).
Recommended: Portable Network Graphics (PNG) v1.2
The Portable Network Graphics283 (PNG) format can be used. This format is license-free. It
supports 16 million colours, transparency, loss-free compression, incremental display of
graphics (beginning with the gross structure until the file is completely transmitted) and
the identification of damaged files. The format was standardized by ISO (ISO/IEC
15948:2003284).
Recommended: Tagged Image File Format (TIFF) v6.0
TIFF285 can be used for saving bit-mapped graphics. TIFF is supported by all conventional
graphic and presentation programs. In order to achieve maximum interoperability, the
properties of the "Baseline TIFF"286 must be used exclusively. TIFF can be used when the
format must be capable of presenting documents consisting of several pages. TIFF is
281 Refer to http://www.w3.org/Graphics/GIF/spec-gif89a.txt
282 Refer to http://www.jpeg.org/index.html?langsel=de, standardized as ISO/IEC 10918-1:1994,
refer to http://www.iso.org/, standardized as ITU-T.81, refer to http://www.itu.int/rec/T-RECT.81/en
283 Refer to http://www.w3.org/TR/PNG/
285 Refer to http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
286 "Baseline TIFF" compiles the properties of TIFF files which should support each program
with TIFF capability. For instance, the two compression methods "Huffmann" and
"Packbits" belong exclusively to "Baseline TIFF" whilst "LZW", "JPEG", "ZIP" and "CCITT" are
optional extensions which are not implemented in every program with TIFF capability.
116
SAGA 4.0
particularly suitable for scanned text documents (b/w graphics or graphics with grey
shades).
Recommended: Geo Tagged Image File Format (GeoTIFF)
GeoTIFF287 is an extension of TIFF v6.0. A geo-reference is additionally featured in the file
header so that contrary to conventional TIFF, the geo-reference file *.tfw does not have to be
created. The GeoTIFF format is supported by established geo-information systems.
Under observation: Joint Photographic Experts Group 2000 (JPEG2000) / Part 1
JPEG 2000288 is the successor to JPEG and is not yet widely used. Offering the same quality, it
features higher compression than JPEG. Together with the use of metadata, JPEG 2000 is
suitable for recording geo-data289. Browser support for JPEG 2000 is only available using
plug-ins. Classification of JPEG 2000 is limited to the first part of the ISO standard290 because
this contains the core functionality and is the most useful standard.
8.6.9 Animation
Mandatory: Animated Graphics Interchange Format (Animated GIF) v89a
Animation means moving features in graphics displayed on a website. Animated GIF, a
variant of GIF graphic format291 should be the product of choice here. With this format,
several individual GIF images are stored in a file, with the possibility to define their
sequence, display time and number of repetitions.
8.6.10 Audio and video data
8.6.10.1
Interchange formats for audio and video files
Recommended: Quicktime
The customary Quicktime format292 should be used to exchange video sequences. A suitable
plug-in enables a web browser to "play" such files.
Recommended: MPEG-4 Part 14 (MP4)
MP4 is the official container format for MPEG-4 which was developed by the Moving Picture
Experts Group and standardized as ISO/IEC-14496293. MP4 is known as part 14 of the MPEG-4
287 Refer to http://www.remotesensing.org/geotiff/
288 Refer to http://www.jpeg.org/jpeg2000/
289 Refer to OGC: "GML in JPEG 2000 Interoperability Experiment (GMLJP2)",
http://www.opengeospatial.org/standards/gmljp2
290 Standardized as ISO/IEC 15444-1:2004, refer to http://www.iso.org/
291 Refer to http://www.w3.org/Graphics/GIF/spec-gif89a.txt
292 Refer to http://quicktime.apple.com/
SAGA 4.0
117
standard. MP4 is an open, manufacturer-independent standard and this format is
supported by many tools and products on different platforms.
MP4 can be used to exchange video files although MPEG-4 should be used as codec.
Recommended: Ogg Encapsulation Format (Ogg)
Ogg294 is an open, manufacturer-independent container format for audio and video files. It
is developed by the Xiph.org Foundation295 and is supported by many media players.
With the Ogg container format, different codes can be used depending on the application
in question. Theora296 can be used for video data. Speex297 is suitable for audio files with low
quality requirements, for example, voice recordings. Vorbis298, which features a quality that
is equivalent to MP3, can be used for audio files with normal quality requirements. Loss-free
Audio-Codec FLAC299 can be used for cases where maximum quality is required.
Under observation: Windows Media Video (WMV) v9
The quality of Windows Media Video (WMV) format is better than that of Quicktime
format. However, patents make the use of WMV format difficult for open source
developers.
Under observation: RealMedia v10
RealMedia from RealNetworks300 is the container format for the RealAudio audio format
and the RealVideo video format. All these formats are proprietary. The quality of RealVideo
exceeds that of the Quicktime format. The free player is available for all conventional
platforms as well as some mobile devices. RealMedia should only be used if the audio-video
data is not to be archived. It is ensured that the files can be played today, however, with a
view to the future, it must be feared that no more players will be available for what will be
then old RealMedia formats.
8.6.10.2
Interchange formats for audio and video streaming
In contrast to "normal" audio and video sequences, audio and video streaming offers a
format that enables playing already during transmission. This enables live transmission of
videos, whereas "normal" audio and video files must be completely transmitted first before
they can be started. This area is occasionally characterized by a slightly confusing mix of
suppliers, products, container and content formats. Since SAGA does not intend to
recommend products, recommendations will be given for the container format only.
What is important here is that the recommendations should be compatible - to the
maximum extent possible – with customary streaming servers and client products. Due to
295 Refer to http://www.xiph.org/ogg/
296 Refer to http://www.theora.org/
297 Refer to http://www.speex.org/
298 Refer to http://www.vorbis.com/
299 Refer to http://flac.sourceforge.net/
300 Refer to http://www.realnetworks.com/
118
SAGA 4.0
the fact that this area has been a field of strong competition for several years, the different
products are currently highly compatible in terms of the formats supported.
Mandatory: Hypertext Transfer Protocol (HTTP) v1.1
In order to reach as many citizens as possible, the server product selected should enable the
transport of streaming data via HTTP301.
Recommended: Quicktime
In order to achieve the maximum possible degree of compatibility between the streaming
signal and commonly used web browsers and video clients and/or plug-ins, Quicktime
format302 should be used, refer to section 8.6.10.1 on page 116.
Recommended: MPEG-4 Part 14 (MP4)
MP4 can be used to stream video sequences. In this case, MPEG-4 should be used as the
codec, refer to section 8.6.10.1 on page 116.
Recommended: Ogg Encapsulation Format (Ogg)
Ogg303 is an open, manufacturer-independent container format that can be used to stream
audio and video.
For information concerning suitable audio and video codecs, refer to section 8.6.10.1
"Interchange formats for audio and video files" on page 116.
Under observation: Windows Media Video (WMV) v9
Under observation: RealMedia v10
When RealMedia is used to stream applications, it must also be considered that the prices
for the RealMedia servers, called Helix servers, are high compared to Windows Media
Quicktime. However, the Helix Universal servers also support Windows Media and
Quicktime.
8.6.11 Interchange formats for geo-information
The standards listed below for exchanging geo-information are used in the geo-services in
section 8.7.6 on page 128.
301 Published as RFC 2616, refer to http://www.ietf.org/rfc/rfc2616.txt, further information
available under "HTTP" in section 8.7.5 "Application protocols" on page 126
302 Refer to http://quicktime.apple.com/
SAGA 4.0
119
Recommended: Geography Markup Language (GML) v3.1.1
GML304 is a markup language used to interchange and save geographical information in
vector format which considers spatial and non-spatial properties. This specification was
carried out by the Open Geospatial Consortium (OGC)305. GML does not contain any
information concerning presentation on the screen or in a map.
GML v3.1.1 should be used especially in conjunction with the use of Web Feature Service
(WFS), v1.1, refer to section 8.7.6 "Geo-services" on page 128.
Recommended: Geography Markup Language (GML) v2.1.2
GML v2.1.2 should be used especially in conjunction with the use of Web Feature Service
(WFS), v1.0, refer to section 8.7.6 "Geo-services" on page 128.
8.6.12 Data compression
Compression systems should be used in order to enable the interchange of large files and
minimize network load.
Mandatory: ZIP v2.0
Compressed data should be exchanged in the internationally used ZIP306 version 2.0 format.
Recommended: Gnu ZIP (GZIP) v4.3 / Tape ARchive (TAR)
In order to compress large file archives, the formats GZIP (file extension: .gz), version 4.3,
specified in RFC 1952307, and TAR can be used. The TAR header file is part of POSIX.1-2001 that
is included in ISO/IEC standard 9945308.
In order to create a file archive, all the files must first be compiled with TAR to form an
archive file. The archive file can then be compressed with GZIP (file extension: .tgz or
.tar.gz). In contrast to file archives compressed with ZIP, this so-called solid compression
leads to smaller file sizes because redundant information is compressed across file borders.
8.6.13 Technologies for presentation on mobile devices
In the event that an information offering for mobile phones and PDAs is to be developed,
preference should be given to SMS services because these are widely accepted by citizens.
The presentation of websites for mobile communications is not yet widely used in Germany.
304 Refer to http://www.opengeospatial.org/specs/, published as ISO/PRF 19136, refer to
http://www.iso.org/
305 Refer to http://www.opengeospatial.org/
306 Refer to http://www.pkware.com/business_and_developers/developer/popups/appnote.txt
307 Refer to http://www.ietf.org/rfc/rfc1952.txt
120
SAGA 4.0
In addition to the following technologies, the standards which were generally described for
presenting contents on computers should also be used for mobile devices, refer to sections
8.6.1 to 8.6.12.
Mandatory: Short Message Services (SMS)
The Short Message Service (SMS)309 is part of the GSM mobile communication standard
(Global System for Mobile communication) which is being prepared by the 3rd Generation
Partnership Project (3GPP). 3GPP combines several standardization committees (including
ETSI) and aims to draft technical specifications which precisely describe all aspects of
mobile communication technology.
Under observation: Wireless Application Protocol (WAP) v2.0
The Wireless Application Protocol (WAP)310 v2.0 is a specification for the development of
applications that use wireless communication networks. Its main application is mobile
communications. WAP includes the Wireless Markup Language (WML) v2.0. Compared to
its predecessor version, the presentation possibilities of WAP v2.0 have become much more
similar to those on the World Wide Web. With conventional web browsers, it is not possible
to read WML pages. This means that offers which are to be provided for mobile Internet
applications and for the normal Internet have to be published twice.
WAP v2.0 also contains XHTML Mobile Profile (XHTMLMP)311 which is based on XHTML Basic.
This means that documents which were written in XHTML Basic can be read with WAP-2.0
browsers. XHTMLMP supports various script languages, for example ECMAScript Mobile
Profile (ESMP), a subset of ECMA262312 without extensive computing and memory script
functions.
The majority of mobile devices meanwhile feature WAP 2.0 browsers. However, in the case
of mobiles phones, in general, and PDAs, in particular, there is a growing trend towards
web browsers with full functionality.
Under observation: Extensible Hypertext Markup Language (XHTML) Basic v1.0
XHTML Basic v1.0313 is a standard for presenting HTML pages converted to XML for
applications which do not support the full presentation functionality of HTML (e.g. mobile
phone or PDAs).
XHTML Basic was expanded to XHTML Mobile Profile (XHTMLMP)314 which is contained in
WAP v2.0. This means that documents which were written in XHTML Basic can be read with
WAP-2.0 browsers.
309 Published as 3GPP TS 23.040, refer to http://www.3gpp.org/ftp/Specs/html-info/23040.htm ,
and published as ETSI TS 123 040 V7.0.1, refer to http://www.etsi.org/
310 Refer to http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html
311 Refer to http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp20011029-a.pdf
312 Refer to section 8.6.4 "Active contents" on page 108
313 Refer to http://www.w3.org/TR/2000/REC-xhtml-basic-20001219/
314 Refer to http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp20011029-a.pdf
SAGA 4.0
8.7
121
Communication
Within the "communication" element, a distinction is made between application,
middleware and network protocols as well as directory services.
8.7.1
Middleware communication
In the case of middleware communication, a distinction is made between server
applications that communicate within an administration, refer to section 8.7.1.1, and client
applications outside the administration which communicate with an administration
server, refer to section 8.7.1.2.
The data elements to be transmitted should be specified using the technologies described
in section 8.3 "Data models" on page 96 and section 8.6.6 "Interchange formats for data " on
page 109.
8.7.1.1
Middleware communication within the administration
Mandatory: Remote Method Invocation (RMI)
Java RMI315 is particularly suitable for internal communications between Java objects. Via
RMI, an object on a Java Virtual Machine (VM), can trigger methods of an object that runs
on another Java VM. Java Remote Method Invocation is part of the Java 2 Standard Edition
(Java SE) and hence also part of the Enterprise Edition (Java EE).
Mandatory: Simple Object Access Protocol (SOAP) v1.1
SOAP316 should be used for communications between the party supplying the server and the
user of a server within the meaning of the SOA reference model317. SOAP can be used to
exchange structured data as XML objects between applications or their components via an
Internet protocol (e.g. via HTTP).
Mandatory: Web Services Description Language (WSDL) v1.1
The Web Services Description Language (WSDL) should be used for service definition
purposes. WSDL is a standardized language318 that describes web services in such a manner
that they can be used by other applications without the need to know further details of the
implementation or to use the same programming language.
Mandatory: Java Message Service (JMS) v1.1
JMS319 is used to generate, send, receive and read messages. JMS API defines a uniform
interface that enables Java programs to communicate messages to other massaging
315
316
317
318
319
Refer to http://java.sun.com/rmi/
Refer to http://www.w3.org/TR/soap11/
Refer to Fig. 6-2 on page 69
Refer to http://www.w3.org/TR/wsdl
Published as JSR-000914, refer to http://www.jcp.org/en/jsr/detail?id=914
122
SAGA 4.0
systems. The advantage of communication with messages is the loose link. JMS ensures that
the messages are sent in an asynchronous and reliable manner.
JMS should then be used when components communicating with each other are not to be
disclosed with a view to their interfaces (easier exchangeability) and when communication
between the components is to be generally asynchronous and error-tolerant.
Mandatory: J2EE Connector Architecture (JCA) v1.5
JCA320 should be used to integrate existing systems into Java applications and/or to
communicate with them. This means that the systems must provide so-called resource
adapters. A resource adapter must be created just once for each legacy system and can then
be reused in all environments for Java Enterprise Editions (Java EE). The JCA resource
adapter frequently uses messages, such as JMS, in order to communicate with legacy
systems.
Recommended: Java Language Mapping to OMG IDL
The most well-known implementation of the Java Language Mapping to OMG IDL321
specification, which was published by OMG, is Remote Method Invocation over Internet
Inter ORB Protocol (RMI-IIOP) from Sun.
Java RMI-IIOP322 is an integral part of Java Standard Edition (Java SE) and hence also part of
the Enterprise Edition (Java EE). Distributed Java applications can communicate via RMIIIOP with remote applications via CORBA. RMI-IIOP communication can be carried out with
all Object Request Brokers which conform to the latest CORBA specification 2.3.1323. The
remote applications are hence not limited to the Java language.
Recommended: Web Services (WS) Security v1.1
WS-Security324 is an OASIS standard for secure web services. It defines upgrades of the SOAP
protocol in order to provide and ensure confidentiality, integrity and the binding effect of
SOAP messages for securing web services. WS-Security supports the signing and encryption
of SOAP messages based on XML Signature and XML Encryption. The use of different
security models and different cryptographic method must be possible.
WS-Security also enables different "security tokens", i.e. data formats which warrant
specific identities or properties, e.g. X.509 certificates, Kerberos Tickets, SAML tokens or
encrypted keys.
The specification of WS-Security consists of the "WS-Security Core Specification 1.1" and the
following profiles:
a. Username Token Profile 1.1
b. X.509 Token Profile 1.1
320
321
322
323
324
Refer to http://www.omg.org/docs/ptc/00-01-06.pdf
Refer to http://java.sun.com/products/rmi-iiop/
Refer to http://omg.org/cgi-bin/doc?formal/99-10-07
Refer to http://www.oasis-open.org/specs/index.php#wssv1.1
SAGA 4.0
123
c. SAML Token profile 1.1
d. Kerberos Token Profile 1.1
e. Rights Expression Language (REL) Token Profile 1.1
f.
SOAP with Attachments (SWA) Profile 1.1
The token profiles specify how the different tokens can be used in SOAP.
Under observation: Universal Description, Discovery and Integration (UDDI) v2.0
The UDDI protocol is the basis for designing a standardized, interoperable platform that
permits the simple, fast and dynamic search for web services. The further development of
UDDI is being promoted within the scope of OASIS325. UDDI is based on standards issued by
the W3C and the Internet Engineering Task Force (IETF), such as XML, HTTP, DNS and SOAP.
8.7.1.2
Middleware communication with applications outside the administration
Web services should be used for access by client applications via the Internet to server
applications at administrations.
By providing a web service layer for an existing server application, client systems are
enabled to trigger the functions of the applications via the Hypertext Transfer Protocol
(HTTP). A web service is a service which can be made up of components and which uses
SOAP to communicate with other components via the HTTP standard protocol. XML is used
for the message content itself. XML was already described in section 8.3 "Data models" on
page 96 as a universal and primary standard for exchanging data between all the
information systems relevant for administrative purposes.
The Web Service Interoperability Organization (WS-I) defines profiles of existing standards
in order to facilitate the compilation of the required standards. The profile to be applied is
WS-I-Basic v1.1326 and includes XML Schema v1.0, SOAP v1.1, WSDL v1.1 and UDDI v2.0.
325 Refer to http://www.uddi.org/
326 Refer to http://www.ws-i.org/Profiles/BasicProfile-1.1.html
124
SAGA 4.0
8.7.2
Network protocols
Mandatory: Internet Protocol (IP) v4
The federal administration's IT environment currently uses IP v4 (RFC 791327, RFC 1700328) in
conjunction with TCP (Transmission Control Protocol, RFC 793329) and UDP (User Datagram
Protocol, RFC 768330).
When new components of a system are to be introduced, these new components should
support both IP v4 and IP v6 in order to enable future migration.
Mandatory: Domain Name System (DNS)
Since the mid-1980s, the Domain Name System (DNS, RFC 1034331, RFC 1035332) has been the
standard on the Internet. DNS refers to a hierarchical name server service at central points
of the Internet. This is where a server name entered is converted to the pertinent IP address.
Under observation: Internet Protocol (IP) v6
IP v6333 is the next version of the IP protocol which up to now has not been very widely used.
One of the changes compared to the current version 4 is the extension of the IP address to
128 bits in order to permit addressing of multi-embedded and mobile IP-based systems in
future.
IP v6 includes IPsec (IP-Security Protocol) which is chiefly used in the VPN (Virtual Private
Network) area and which can also be used independent of IP v6. Thanks to the use of VPNs
with secure encryption methods, the transport channel and the authentication of terminal
systems is ensured in the manner required, for instance, for wireless networks (Wireless
Local Area Network – WLAN) and also for home offices or in site networking. Information
on IPsec and VPN is available, for instance, from the German Federal Office for Information
Security334.
327
328
329
330
331
332
333
334
Refer to http://www.ietf.org/rfc/rfc791.txt
Refer to http://www.ietf.org/rfc/rfc2460.txt und http://www.ietf.org/rfc/rfc3041.txt
Refer to http://www.bsi.de/, e.g. "Aufbau von Virtual Private Networks (VPN) und
Integration in Sicherheitsgateways" [Establishment of Virtual Private Networks (VPNs) and
integration into security gateways] at
http://www.bsi.de/fachthem/sinet/loesungen_transport/VPN.pdf
SAGA 4.0
8.7.3
125
E-mail communication
Mandatory: Simple Mail Transfer Protocol (SMTP) / Multipurpose Internet Mail Exten
sions (MIME) v1.0
E-mail protocols that comply with the SMTP / MIME335 specifications for exchanging
messages (RFC 2821, RFC 2045 to RFC 2049)336 are required for e-mail transport.
E-mail attachments should correspond to the file formats defined in section 8.6 on page
105.
Mandatory: Post Office Protocol (POP) v3 / Internet Message Access Protocol (IMAP)
v4rev1
In exceptional cases, it may be necessary to offer electronic mailboxes. In this case, POP3337
or IMAP338 should be used as the commonly used standards.
v1.1., Part 1 to Part 6
The secure exchange of e-mails is one possible application for the "communication"
interaction stage. Secure e-mail communication includes securing e-mails during their
transmission from a sender to a recipient. This application looks at e-mails in their entirety.
Section 8.6.7.7 "Secured document exchange" on page 113 discusses the procedures for
securing documents, including e-mail attachments.
Taking the basic functions of the electronic signature, encryption and authentication, the
ISIS-MTT specification considers a host of applications for processes to secure electronic
business (for example, file, mail, transaction and time "protection"), refer to section 8.1.4
"Implementation of the security concept" on page 93.
Parts 1 to 6 are especially relevant for securing e-mail communications.
8.7.4
IP telephony
Voice or telephony is an important and established channel of communication for citizens,
business and public agencies. Public agencies are also already running call centres and
sometimes make use of telephone systems with Voice-over-IP (VoIP). With this form of
communication, the interfaces in the field of presentation must be offered to the outside
world and the interfaces in the backend with eGovernment applications must be made
available (Computer Telephony Integration – CTI). This means that context-related VoIP
connections to the respective specialized officers or call-centre employees can be offered to
customers on websites and data received is displayed to the employee without media
inconsistencies.
335
336
337
338
Refer to section 8.6.3 "Technologies for information processing" on page 106
Refer to http://www.ietf.org/rfc.html
Published as RFC 1939, refer to http://www.ietf.org/rfc/rfc1939.txt
Published as RFC 3501, refer to http://www.ietf.org/rfc/rfc3501.txt
126
SAGA 4.0
Recommended: H.323
The protocol for signalling according to the ITU-T's standard H.323339 together with the
protocols that belong to this family should be used to transport data for IP telephony.
Under observation: Session Initiation Protocol (SIP) v2.0
SIP is a standard for signalling with IP telephony (RFC 3261340) which was drawn up by IETF.
It can be used together with the supplementary protocols for data transmission as an
alternative to H.323.
8.7.5
Application protocols
Section 8.1.4 "Implementation of the security concept" on page 93 deals with the
connection of security-related infrastructures (e.g. directory services for certificates,
revocation lists, etc).
Mandatory: File Transfer Protocol (FTP)
File Transfer Protocol (FTP, RFC 959341) is considered the standard for file transfer. FTP is one
of the oldest Internet services. FTP enables the shared use of files, it offers users
standardized user interfaces for different file system types, and transfers data in an efficient
and reliable manner. FTP is typically somewhat faster than HTTP when larger files are to be
downloaded.
Since FTP does not encrypt any data, including passwords, before sending, it should not be
used for applications with a high security requirement. In such cases, secured methods,
such as SSH-2 and TLS, which are also described in this section, must be used.
Mandatory: Hypertext Transfer Protocol (HTTP) v1.1
HTTP v1.1 (RFC 2616342) should be used for communications between the client and web
server. However, web servers should also support HTTP v1.0 (RFC 1945343) in addition to
version 1.1. The HTTP State Management Mechanism (RFC 2965344) standard should be
adopted when HTTP Session Management and cookies are used. In contrast to version 1.0,
the upload and download functionality of HTTP v1.1 offers the option of so-called "web
folders" (refer to WebDAV on page 128). Chat systems can initiate the reloading of websites
via HTTP v1.1.
339
340
341
342
343
344
Refer to http://www.itu.int/rec/T-REC-H.323/en
SAGA 4.0
127
Mandatory: Online Service Computer Interface (OSCI) Transport v1.2
The Online Service Computer Interface (OSCI)345 is the result of the MEDIA@Komm
competition. OSCI covers a host of protocols which are suitable for eGovernment
requirements and which are implemented by the OSCI steering group. The aim is to
support transactions in the form of web services and their complete handling via the
Internet.
OSCI Transport 1.2 is that part of "OSCI" which is responsible for the cross-section tasks in the
security area. The existence of a central intermediary which can perform added-value
services without jeopardizing confidentiality at the business case data level is a
characteristic feature of the secure implementation of eGovernment processes using OSCI.
As a secure transmission protocol, it enables binding online transactions (even in
conformance to the German Act on Digital Signature).
OSCI Transport supports asynchronous communication via an intermediary as well as endto-end encryption for the confidential transmission of data. OSCI Transport standardizes
both message contents as well as transport and security functions and is based on
international standards (including, for instance, XML Signature, DES, AES, RSA and X.509)
for which suitable, concrete contents are developed as required.
Central design criteria for OSCI Transport, version 1.2, were the following.
a. Reference to open standards (SOAP, XML Signature, XML Encryption)
b. Technical independence, i.e. transmission using any technical communication protocol
without any specific requirements regarding platforms or programming languages
c. Scalability of security levels (advanced signatures or qualified and/or accredited
electronic signatures as required by the specific application).
Mandatory: Transport Layer Security (TLS) v1.0
TLS346 is a cryptographic protocol that ensures the integrity and confidentiality of a
communication connection on the World Wide Web. It was developed from the Secure
Sockets Layer (SSL) protocol. The SSL v3 standard, which was still mandatory in SAGA version
2.1, is listed in the Right of Continuance List. For security reasons, older SSL standards should
no longer be used for existing applications.
TLS is based on TCP/IP and secure communication protocols for applications, such as HTTP,
IIOP, RMI, etc., in a transparent manner. TLS-secured web pages are addressed with https://
rather than http://.
TLS also supports the single-ended authentication of the public agency's server in relation
to the client of the communication partner in order to confirm to the latter that it is really
connected to the public agency's server. Double-ended authentication of client and server
can also be supported by TLS.
TLS offers the following cryptographic mechanisms.
345 Refer to http://www.osci.de/
128
SAGA 4.0
a. Asymmetric authentication of the communication partners (via X.509 certificates)
b. Secure exchange of session keys (via RSA encryption or Diffie-Hellman key agreement)
c. Symmetric encryption of communication contents
d. Symmetric message authentication (via MACs) and protection against reply attacks
The principles of operation of TLS are described in detail in section 5.2.2 of the Guideline for
the Introduction of the Electronic Signature and Encryption in the Administration issued by
the Co-operation Committee for Automatic Data Processing for the Federal-government,
Federal-state Government and Municipal Administration Sector (KoopA ADV)347. In TLS, the
combination of different methods is referred to as a "cipher suite". A TLS cipher suite always
contains four cryptographic algorithms: a signature method, a key exchange method, a
symmetric encryption method as well as a hash function.
Recommended: Secure Shell v2 (SSH-2)
The SSH-2348 protocol is an enhanced version of the SSH which has existed since 1995. Using
a standardized authentication procedure, it enables the opening of an encrypted tunnel
between the client and server system and then permits encrypted user data to be sent and
received via the transport layer. The different open-source and commercial
implementations of this protocol enable strong encryption of user data and allow, for
instance, remote control of remote computers and file transfer (SSH-FTP). This means that
there is a secure alternative to FTP.
Recommended: WWW Distributed Authoring and Versioning (WebDAV)
WebDAV349 is a standard drafted by the Internet Engineering Task Force (IETF) which can be
used as an extension of HTTP for writing and changing files in networks. It is hence an
alternative to FTP. In contrast to FTP, when data is transmitted with WebDAV, no additional
port has to be released because WebDAV uses the HTTP port 80. Write access based on
passwords should be encrypted, e.g. via HTTPS or TLS. However, not all applications that
support WebDAV also support so-called encryption mechanisms.
Under observation: Transport Layer Security (TLS) v1.1
Adopted in April 2006, TLS v1.1350 is a further development of TLS v1.0 that features
improved security. Support of TLS v1.1 is planned for the next generation of web browsers.
8.7.6 Geo-services
All standards in this section are either specifications of the Open Geospatial Consortium
(OGC)351 or are based on these specifications. The classifications were agreed to with Geo
347 Refer to http://www.koopa.de/projekte/pki.html
348 Published under RFC 4251 - 4256, refer to http://www.ietf.org/rfc.html
349 Published as RFC 2518, refer to http://www.ietf.org/rfc/rfc2518.txt and
http://www.webdav.org/
351 Refer to http://www.opengeospatial.org/
SAGA 4.0
129
dateninfrastruktur Deutschland [Geo-data infrastructure Germany] (GDI-DE)352 and are
orientated towards [GDI-DE 2007]. The definition of formats for exchanging geoinformation can be found in section 8.6.11 on page 118.
Recommended: Catalogue Services Specification v2.0 – ISO Metadata Application
Profile v1.0
The Catalogue Services Specification v2.0 – ISO Metadata Application Profile353 is an
application profile for catalogue services which was adopted by the OGC. The profile refers
to the CSW base specification of OGC and the metadata specifications of ISO (ISO 19115, ISO
19119). It should be used to implement standard-compliant metadata searches.
Recommended: Web Map Service Deutschland (WMS-DE) v1.0
The aim of the WMS-DE354 profile is to define in a binding manner the requirements of
Geodateninfrastruktur Deutschland (GDI-DE) for a Web Map Service (WMS). With WMS
services which use this profile, the user can achieve a nation-wide presentation by
combining the digital maps and data of various WMS services. The binding parameters
within the scope of GDI-DE should benefit both suppliers during the establishment of
services as well as users during queries.
Recommended: Web Coverage Service (WCS) v1.0.0
WCS355 enables access to multi-dimensional grid data. This service is particularly suitable
for submitting grid data, e.g. in shop solutions, for providing measured values in the form
of time series, and for supplying digital terrain models.
Recommended: Web Feature Service (WFS) v1.0
WFS v1.0.0356 enables access to geo-data objects (features), usually in the form of vector data.
Data is exchanged in the Geography Markup Language (GML) v2.1.2, refer to section 8.6.11
"Interchange formats for geo-information" on page 118.
Recommended: Web Feature Service (WFS) v1.1
Compared to its predecessor version 1.0.0, WFS v1.1.0357 is not yet so widely used. Data is
exchanged in the Geography Markup Language (GML) v3.1.1, refer to section 8.6.11
"Interchange formats for geo-information" on page 118.
352
353
354
355
356
357
Refer to http://www.gdi-de.org/
Refer to http://www.opengeospatial.org/standards/cat
Refer to http://www.gdi-de.org/de/download/WMS_DE_Profil_V1.pdf
Refer to http://www.opengeospatial.org/specs/
130
SAGA 4.0
Recommended: Simple Feature Access – Part 2: SQL option (SFA-2) v1.1.0
SFA-2358 defines interfaces for accessing geo-data objects (features). Along with OGC, this
standard was standardized by ISO and is hence also called ISO 19125-2359.
8.8
Backend
The German administration uses several legacy systems which are very likely to remain in
use even in the future (e.g. ERP, mainframe transaction processing, database systems and
other legacy applications). Depending on the operating modes supported, these legacy
systems can be divided into three categories as follows:
a. Transaction-secured processing by end users via existing dialogue systems,
b. asynchronous data batch processing (bulk data processing) and
c. program-to-program communication on the basis of proprietary protocols.
Two options are generally available for integrating legacy systems:
a. Direct integration via so-called "legacy interfaces" or
b. integration via a separate integration tier, with modular encapsulation of real access to
the legacy systems.
Detailed solution concepts must be evaluated and compared with a view to the aims to be
achieved, the time and budget available, as well as the functions to be supported during the
integration of the legacy system.
The following sections discuss different solution concepts which have proven to be suitable
with the three above-mentioned operating modes.
The data elements to be transmitted should be specified using the technologies described
in section 8.3 "Data models" on page 96 AND section 8.6.6 "Interchange formats for data "
on page 109.
8.8.1
Directory services and registries
Mandatory: Lightweight Directory Access Protocol (LDAP) v3
LDAP v3 (RFC 4510 - 4519360) is an X.500-based Internet protocol which is optimized with
regard to hierarchically structured information and which is used for directory service
access.
Analogous to section 8.7.1.2 "Middleware communication with applications outside the
administration" on page 123.
358 Refer to http://www.opengeospatial.org/specs/
360 Refer to http://www.ietf.org/rfc/rfc4510.txt
SAGA 4.0
131
Under observation: Directory Services Markup Language (DSML) v2
DSML361 is an XML-based language which is used to exchange data with directory services –
e.g. during the course of queries and updates. Use of the specification makes it easy to
access the directory services. DSML v2 was published in 2001 as an OASIS standard.
Under observation: ebXML Registry Services and Protocols (ebXML RS) v3.0/ ebXML
Registry Information Model (ebXML RIM) v3.0
ebXML RS describes the services and protocols offered by an ebXML-compliant registry. An
ebXML registry is a system that safely administers any particular content and the related,
standardized metadata. ebXML RIM describes the pertinent information model. The
technologies should be used together.
ebXML RS v3.0362 and ebXML RIM v3.0363 were adopted by OASIS364 on 1 May 2005 as OASIS
standards. Compared to version 2.0, version 3.0 adds many useful features, such as
versioning repository contents.
8.8.2 Access to databases
Mandatory: Java Database Connectivity (JDBC) v3.0
JDBC365 should be used for access to databases.
8.8.3 Access to legacy systems
Mandatory: Remote Method Invocation (RMI)
Analogous to section 8.7.1.1 "Middleware communication within the administration" on
page 121.
page 121.
page 121.
361
362
363
364
365
Refer to http://www.oasis-open.org/specs/index.php#dsmlv2
Refer to http://www.oasis-open.org/specs/index.php#ebxmlrsv3.0
Refer to http://www.oasis-open.org/specs/index.php#ebxmlrimv3.0
Refer to http://www.oasis-open.org/
132
SAGA 4.0
Mandatory: Java Message Service (JMS) v1.1
page 121.
Mandatory: J2EE Connector Architecture (JCA) v1.5
page 121.
Recommended: Java Language Mapping to OMG IDL
page 121.
page 121.
8.9 Encryption
Cryptographic algorithms for encryption can be applied to data and/or keys in order to
ensure their confidential transmission.
8.9.1
Asymmetric encryption methods
Asymmetric encryption methods are required, for example, in order to exchange a socalled session key between communication partners. A session key is a symmetric key, refer
to section 8.9.2 on page 132.
Mandatory: RSA
The RSA method366 is the most important asymmetric method; it is also referred to as the
public key method. During encryption, the bit sequence is encrypted using the public key
of the communication partner. After this, the resultant encrypted secret text can only be
decrypted to plain text by the holder of the private key. The security of this method is based
on the difficulty to factorize large natural numbers. Normal key lengths are 2048 and 4096
bits. The Federal Network Agency no longer recommends 1024-bit keys.
RSA is used during encryption just like signing, refer to section 8.10.2 on page 134.
8.9.2 Symmetric encryption methods
Symmetric methods, when applied, use the same private key for encryption and
decryption. These methods usually feature very high performance.
366 RSA was named after its inventors: Ronald L. Rivest, Adi Shamir and Leonard Adleman
SAGA 4.0
133
Mandatory: Advanced Encryption Standard (AES)
AES367 is a symmetric block cipher with a fixed block length of 128 bits and a key length that
can be either 128, 192 or 256 bits long. AES was published in October 2000 by the National
Institute of Standards and Technology (NIST)368.
The Triple Data Encryption Standard (Triple-DES, also called 3DES), which was still
recommended in SAGA version 2.1, is now on the Right of Continuance List.
8.10 Electronic signature
The security of an electronic signature is primarily dependent upon the strength of the
underlying cryptographic algorithms. With regard to the "electronic signature" issue, refer
also to section 4.5.1 on page 45.
Mandatory: Cryptographic algorithms for the electronic signature according to the
Federal Network Agency
Every year, the Federal Network Agency publishes in the Federal Gazette those
cryptographic algorithms which can be considered to be suitable for at least the next six
years with a view to the requirements of the Act on Digital Signature (SigG) and the Digital
Signature Ordinance (SigV)369. To this effect, the minimum dimensions of parameters, such
as block sizes and key lengths, are stated which are needed to ensure sufficient security. The
German Federal Office for Information Security (BSI) can classify further methods as
suitable.
An electronic signature for the purposes of the Act includes the following cryptographic
algorithms.
8.10.1 Hashing data
A hash function reduces the data to be signed to a hash value, i.e. a bit sequence with a fixed
length. This then means that the hash value rather than the data itself is signed.
Mandatory: Secure Hash Algorithm (SHA)-256
SHA-256 (Secure Hash Algorithm)370, as a further development of SHA-1 (160-bit long hash
value), is a cryptographic hash function that generates a 256-bit long hash value.
367 Refer to http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf, published as FIPS 197
368 Refer to http://csrc.nist.gov/
369 Refer to
http://www.bundesnetzagentur.de/enid/Veroeffentlichungen/Algorithmen_sw.html
370 Published as FIPS PUBS 180-2, refer to http://csrc.nist.gov/publications/fips/fips180-2/fips1802.pdf
134
SAGA 4.0
Recommended: Secure Hash Algorithm (SHA)-224 / Secure Hash Algorithm (SHA)-384 /
Secure Hash Algorithm (SHA)-512
SHA-224, SHA-384 und SHA-512 (Secure Hash Algorithm)371 are further developments of
SHA-1 (160-bit long hash value) and constitute cryptographic hash functions that generate
longer hash values (the length corresponds to the number stated).
8.10.2 Asymmetric signature methods
An asymmetric signature method consists of a signing and a verification algorithm. The
signature method is dependent on a key pair which consists of a private (i.e. secret) key for
signing (generating) and the pertinent public key for verifying (checking) the signature.
Mandatory: RSA
Analogous to section 8.9.1 "Asymmetric encryption methods" on page 132, RSA should be
used for the asymmetric signature method.
Recommended: Digital Signature Algorithm (DSA)
The Digital Signature Algorithm (DSA)372 is the signature method that was specified in the
US Digital Signature Standard (DSS) in 1991. DSA is a pure signature algorithm. Although the
US government has obtained a patent for DSS, its use is free. DSA is less widespread than
RSA. The Federal Network Agency's algorithm catalogue foresees qualified electronic
signatures starting in 2008 as opposed to the standard with bigger parameter lengths.
Normal key lengths are 2048 and 4096 bits. The Federal Network Agency no longer
recommends 1024-bit keys.
8.10.3 Key management
As a precondition for applications to use electronic signatures, it must be possible to assign
public electronic keys (public keys) to real individuals or institutions. In order to achieve
interoperability between different applications, identical data formats must be in place,
and standardized mechanisms must be used to read and write data.
Recommended: XML Key Management Specification (XKMS) v2
XKMS373 specifies protocols for the registration and distribution of public keys. The
protocols were designed for interaction with XML Signature and XML Encryption and are
hence used for XML-based communications, e.g. web services. The specification consists of
two parts, i.e. the XML Key Registration Service Specification (X-KRSS) and the XML Key
Information Service Specification (X-KISS).
371 Published as FIPS PUBS 180-2, refer to http://csrc.nist.gov/publications/fips/fips180-2/fips1802.pdf
372 Published as FIPS 186-2, refer to http://csrc.nist.gov/publications/fips/fips186-2/fips186-2change1.pdf
373 Refer to http://www.w3.org/TR/xkms2/
SAGA 4.0
135
Clients can use relatively simple XKMS queries to find and validate public keys, with relay
servers accessing existing LDAP and OCSP infrastructures in order to answer these queries.
This means that parallel use of different directory services is possible with just one protocol.
8.11 Smartcards
Smartcards are chip cards with an integrated processor; they are also referred to as
microprocessor cards. In contrast to chip cards which are used to only save data (memory
cards), smartcards can also process data. Smartcards can serve as a Personal Security
Environment (PSE), in order to safely store trustworthy certificates and keys, and also as a
(secure) signature generation unit.374
A distinction is made between contact smartcards and contactless smartcards. Whilst
contact smartcards feature a visible, exterior contact surface, contactless smartcards
establish contact with the reader devices by wireless communication (Radio Frequency
IDentification – RFID).
8.11.1 Contact smartcards
Mandatory: Identification Cards - Integrated circuit cards
Contact smartcards should conform to the ISO/IEC 7816375 standard. The standard describes,
for instance, dimensions, positioning contacts and labelling, electrical properties as well as
transmission protocols.
8.11.2 Contactless smartcards
Mandatory: Identification Cards - Contactless integrated circuit cards
Contactless smartcards with a transmission rate of up to approx. 847 kbps – corresponding
to a range of up to 0.1m – should conform to the ISO/IEC 14443376 standard. The standard
describes in four parts the design, function and operation of these smartcards. The
electronic passport377 is based on this standard. The electronic ID card, which is currently in
the planning phase, is also to be based on this standard.
374 Refer to the German Federal Office for Information Security (BSI): "Grundlagen der
elektronischen Signatur – Recht, Technik, Anwendung" [Fundamentals of the electronic
signature - law, technology, application], 2006, http://www.bsi.de/esig/esig.pdf
136
SAGA 4.0
8.11.3 Reader units and interfaces for smartcards
Mandatory: Technical guideline for federal-government eCard projects (BSI TR-03116)
v1.0
Smartcard applications which use cryptographic methods should consider the security
requirements for the use of cryptographic methods in federal-government eCard projects
described in technical guideline BSI TR-03116378 from the Federal Office for Information
Security (BSI) .
v1.1., Part 7
Components which support the universal "Cryptographic Token Interface" (Cryptoki)
should conform to ISIS-MTT379 v1.1, Part 7 (Cryptographic Token Interface).
Under observation: Interoperability Specification for ICCs and Personal Computer Sys
tems (PC/SC) v2.0
PC/SC380 specifies an interface between card reader units and the applications.
Under observation: OpenCard Framework (OCF) v1.2
OCF381 specifies an interface between card reader units and the applications.
Under observation: Secure Interoperable ChipCard Terminal (SICCT) v1.10
SICCT382 describes a basic concept for application-independent terminals for smartcards
based on ISO/IEC 7816 and ISO/IEC 14443383. Applications with high or very high security
requirements can attempt to conform to SICCT.
8.12 Long-term archiving
With electronic documents becoming increasingly widespread in administrations,
sustainable and long-term storage calls for standards for storage which warrant the
authenticity and completeness of the documents.
378
379
380
381
382
Refer to http://www.bsi.bund.de/literat/tr/tr03116/BSI-TR-03116.pdf
Refer to http://www.isis-mtt.org/
Refer to http://www.pcscworkgroup.com/specifications/specdownload.php
Refer to http://www.opencard.org/index-downloads.shtml
Refer to
http://www.teletrust.de/fileadmin/files/publikationen/Spezifikationen/SICCT_Spezifikation
_1.10.pdf
SAGA 4.0
137
Recommended: Tagged Image File Format (TIFF) v6.0
TIFF v6.0 should be used for the long-term archiving of graphics and b/w images. Maximum
interoperability is particularly important in this area of application. This is why only
properties from "Baseline TIFF" are to be used here, refer also to section 8.6.8 on page 115.
Recommended: Joint Photographic Experts Group (JPEG)
In analogy to section 8.6.8 "Interchange formats for graphics" on page 115, JPEG should be
used for long-term archiving of images, in particular, for photos.
Recommended: Extensible Markup Language (XML) v1.0
XML is suitable for long-term archiving, however, the related schemas and XSL files must
also be archived, refer to section 8.6.6 "Interchange formats for data " on page 109.
Examples of XML-based languages for long-term archiving include Encoded Archival
Description (EAD)384, Encoded Archival Context (EAC)385 and the Metadata Encoding and
Transmission Standard (METS)386.
Recommended: ArchiSig, Grundsätze für die beweiskräftige und sichere
Langzeitarchivierung digital signierter Dokumente [principles for conclusive
and secure long-term archiving of electronically signed documents]
The ArchiSig387 project was carried out by various participants from the worlds of science
and industry as well as with users under the leadership of Informatikzentrum
Niedersachsen [Lower Saxon Computer Science Centre] and Staatliche Archivverwaltung
Niedersachsen [Lower Saxon state archive administration]. It defines principles388 that
should be observed for the long-term archiving of electronically signed documents.389
Recommended: Portable Document Format Archive - 1 (PDF/A-1)
The PDF/A-1390 standard (ISO 19005-1:2005391) is based on PDF v1.4, refer to section 8.6.7.1,
with the restrictions that scripts are embedded and metadata is captured and no passwords,
executable code or audio or video data are used.
Conformance to ISO 19005-1:2005 can be described on two different levels:
1.
384
385
386
387
388
389
PDF/A-1b (also referred to as Level B Conformance) represents minimum conformance
to the requirement that the generated appearance of the PDF file must be reproducible
on a long-term basis.
Refer to http://www.loc.gov/ead/
Refer to http://jefferson.village.virginia.edu/eac/
Refer to http://www.loc.gov/standards/mets/
Refer to http://www.archisig.de/
Refer to http://www.archisig.de/grundsaetze.pdf
ArchiSig is used, for instance, within the scope of the "ArchiSafe" project, refer to
http://www.archisafe.de/
390 Refer to http://www.adobe.de/products/acrobat/pdfs/pdfarchiving.pdf
138
SAGA 4.0
2. PDF/A-1a (also referred to as Level A Conformance) is based on Level B and additionally
requires that the PDF file can be searched (text extraction). PDF/A-1a fully complies with
the requirements of the ISO standard (full conformance).
The standard should be used for the long-term archiving of text and presentations. This
standard recognized by ISO can be used to save the document contents, the document form
and the metadata of the document in one archived file. The file can also be displayed
without the original application. A barrier-free presentation of contents is also provided.
Under observation: Extensible Markup Language (XML) v1.1
Analogous to section 8.6.6 "Interchange formats for data " on page 109.
SAGA 4.0
Appendix A References
[APEC]
National Office for the Information Economy / CSIRO: APEC e-Business: What do
Users need?, 2002
http://nla.gov.au/nla.arc-25067
http://www1.cmis.csiro.au/Reports/APEC_E-commerce.pdf
[BOL]
Federal Ministry of the Interior (editor): BundOnline 2005: Umsetzungsplan 2004 –
Status und Ausblick, Dresden 2004
http://www.kbst.bund.de/ (in the area of > eGovernment > Initiatives
> BundOnline 2005 > Implementation plan and final report > 2004 –
implementation plan)
[BSI 2005]
German Federal Office for Information Security: ITIL und Informationssicherheit –
Möglichkeiten und Chancen des Zusammenwirkens von IT-Sicherheit und IT-ServiceManagement, Berlin, 2005
http://www.bsi.de/literat/studien/ITinf/itil.pdf
[e-GIF]
Office of the e-Envoy: e-Government Interoperability Framework Version 6.0, 2004
http://www.govtalk.gov.uk/schemasstandards/egif.asp
http://www.govtalk.gov.uk/documents/e-gif-v6-0(1).pdf
Office of the e_Envoy: Technical Standards Catalogue Version 6.1, 2004
http://www.govtalk.gov.uk/documents/TSCv6-1_2004-11-15.pdf
[FIPS-PUBS]
National Institute of Standards and Technology (NIST), Information Technology
Laboratory (ITL): Federal Information Processing Standards Publications, 2005
http://www.itl.nist.gov/fipspubs/
[GDI-DE 2007]
Geo-data infrastructure Germany: Architektur der Geodateninfrastruktur
Deutschland, concept for the universal provision of geodata within the scope of
eGovernment in Germany, version 1.0, 2007
http://www.gdi-de.org/de/download/GDI_ArchitekturKonzept_V1.pdf
[IDABC]
European Commission: Interoperable Delivery of European eGovernment Services to
public Administrations, Businesses and Citizens, 2005
http://europa.eu.int/idabc/
139
140
SAGA 4.0
[IEEE 2000]
Institute of Electrical and Electronics Engineers (IEEE): IEEE-Standard 1471-2000:
Recommended Practice for Architectural Description of Software-Intensive Systems,
2000
[ISO 1996]
ISO/IEC 10746-3: Information technology – Open Distributed Processing – Reference
Model: Architecture, Geneva 1996
[ITG 2000]
Informationstechnische Gesellschaft (ITG) im VDE: Electronic Government als
Schlüssel der Modernisierung von Staat und Verwaltung. A memorandum by the
specialist committee for administrative IT of Gesellschaft für Informatik e.V. (GI)
and special unit 1 of Informationstechnische Gesellschaft (ITG) at the Association
for Electrical, Electronic and Information Technologies (VDE), Bonn / Frankfurt
2000
http://mediakomm.difu.de/documents/memorandum.pdf
[KBSt 2007]
KBSt: IT-Architekturkonzept für die Bundesverwaltung, 2007
http://www.kbst.bund.de/architekturkonzept
[Kudraß 1999]
Kudraß, Thomas: Describing Architectures Using RM-ODP, online publication, 1999
http://www.imn.htwk-leipzig.de/~kudrass/Publikationen/OOPSLA99.pdf
[Lenk et al. 2000]
Lenk, Klaus / Klee-Kruse, Gudrun: Multifunktionale Serviceläden, Berlin 2000
[Lenk 2001]
Lenk, Klaus: Über Electronic Government hinaus Verwaltungspolitik mit neuen
Konturen, paper at the 4th conference on administrative IT at the Federal
University of Applied Administrative Sciences on 5 September 2001
[v. Lucke et al. 2000]
Lucke, Jörn von / Reinermann, Heinrich: Speyerer Definition von Electronic
Government. Results of the research project "government and administration in
the information age", online publication, 2000
http://foev.dhv-speyer.de/ruvii/Sp-EGov.pdf
[New Zealand]
State Services Commission, New Zealand: E-government in New Zealand, 2007
http://www.e-government.govt.nz/
[Schedler et al. 2001]
Schedler, Kuno / Proeller, Isabella: NPM, Berne / Stuttgart / Vienna 2001
SAGA 4.0
[Schreiber 2000]
Schreiber, Lutz: Verwaltung going digit@l. Ausgewählte Rechtsfragen der OnlineVerwaltung, in: Digitale Signaturen, in: Kommunikation & Recht, supplement 2 in
edition 10/2000
[Switzerland]
Swiss Federal Chancellery: Sektion elektronischer Behördenverkehr, homepage of
Beratungs-, Dienstleistungs- und Betriebsorganisation für den elektronischen
Behördenverkehr [the advisory, service and provider organization for electronic
communications with public agencies] (E-Government), 2007
http://www.bk.admin.ch/org/bk/00346/00348/index.html?lang=de
[SIGA]
eGovernment project group at the German Federal Office for Information Security
(BSI): Sichere Integration von E-Government-Anwendungen, module of the
eGovernment manual, 2003
http://www.bsi.bund.de/fachthem/egov/4_siga.htm
141
SAGA 4.0
143
Appendix B Overview of Classified
Standards
.NET-Framework...............................................................................................................................100
A
Advanced Encryption Standard (AES)...........................................................................................133
AES......................................................................................................................................................133
Animated GIF.....................................................................................................................................116
Animated Graphics Interchange Format (Animated GIF) v89a................................................116
ANSI/NISO Z39.85...............................................................................................................................97
ArchiSig, Grundsätze für die beweiskräftige und sichere Langzeitarchivierung digital
signierter Dokumente [principles for conclusive and secure long-term archiving of
electronically signed documents]..................................................................................................137
B
Barrierefreie Informationstechnik Verordnung (BITV) [Barrier-free information technology
ordinance].........................................................................................................................................105
BITV....................................................................................................................................................105
BPEL4WS............................................................................................................................................100
BSI, E-Government-Handbuch [eGovernment manual]......................................................95, 104
BSI, IT-Grundschutz-Kataloge [IT Baseline Protection Catalogues]...........................................94
BSI TR-03116.......................................................................................................................................136
BSI standard 100-1: Management systems for Information Security..........................................91
BSI standard 100-2: IT baseline protection approach...................................................................92
BSI-Standard 100-3: Risk analysis on the basis of IT baseline protection...................................93
Business Process Execution Language for Web Services (BPEL4WS) v1.1...............................100
C
C# Language Specification..............................................................................................................99
Cascading Style Sheets Language Level 2 (CSS2)..........................................................................107
Catalogue Services Specification v2.0 – ISO Metadata Application Profile v1.0....................129
CLI.........................................................................................................................................................99
Comma Separated Value (CSV).......................................................................................................112
Common Language Infrastructure (CLI)........................................................................................99
Cryptographic algorithms for the electronic signature according to the Federal Network
Agency................................................................................................................................................133
CSS2.....................................................................................................................................................107
144
SAGA 4.0
CSV.......................................................................................................................................................112
D
DC.........................................................................................................................................................97
DCMI Metadata Terms.......................................................................................................................97
Digital Signature Algorithm (DSA).................................................................................................134
DIN 66001............................................................................................................................................95
Directory Services Markup Language (DSML) v2..........................................................................131
DNS......................................................................................................................................................124
Domain Name System (DNS)...........................................................................................................124
DSA......................................................................................................................................................134
DSML....................................................................................................................................................131
Dublin Core (DC).................................................................................................................................97
E
ebXML Registry Information Model (ebXML RIM) v3.0.............................................................131
ebXML Registry Services and Protocols (ebXML RS) v3.0.............................................................131
ebXML RIM.........................................................................................................................................131
ebXML RS............................................................................................................................................131
ECMA-262..........................................................................................................................................108
ECMA-334............................................................................................................................................99
ECMA-335..........................................................................................................................................100
ECMA-376..............................................................................................................................111, 112, 113
ECMAScript Language Specification.............................................................................................108
eGovernment manual.......................................................................................................................95
Election Markup Language (EML) v4.0.........................................................................................109
EML.....................................................................................................................................................109
Entity Relationship Diagram (ERD).................................................................................................96
ERD.......................................................................................................................................................96
Extensible Hypertext Markup Language (XHTML) Basic v1.0....................................................120
Extensible Hypertext Markup Language (XHTML) v1.0..............................................................107
Extensible Markup Language (XML) v1.0...............................................................................109, 137
Extensible Markup Language (XML) v1.1...............................................................................109, 138
Extensible Stylesheet Language (XSL) v1.0....................................................................................107
Extensible Stylesheet Language (XSL) v1.1....................................................................................108
Extensible Stylesheet Language Transformations (XSLT) v1.0...................................................107
Extensible Stylesheet Language Transformations (XSLT) v2.0...................................................108
SAGA 4.0
145
F
File Transfer Protocol (FTP)..............................................................................................................126
FIPS 186-2............................................................................................................................................134
FIPS 197...............................................................................................................................................133
FIPS PUBS 180-2..................................................................................................................................133
FTP.......................................................................................................................................................126
G
Geo Tagged Image File Format (GeoTIFF).....................................................................................116
Geography Markup Language (GML) v2.1.2..................................................................................119
Geography Markup Language (GML) v3.1.1...................................................................................119
GeoTIFF...............................................................................................................................................116
GIF v89a..............................................................................................................................................115
GML v2.1.2...........................................................................................................................................119
GML v3.1.1............................................................................................................................................119
Gnu ZIP (GZIP) v4.3............................................................................................................................119
Graphics Interchange Format (GIF) v89a......................................................................................115
H
H.323...................................................................................................................................................126
Handlungsleitfaden für die Einführung der elektronischen Signatur und Verschlüsselung
in der Verwaltung v1.1 [Guideline for the Introduction of the Electronic Signature and
Encryption in the Administration]..................................................................................................94
HTML............................................................................................................................................110, 113
HTML v4.01........................................................................................................................................106
HTTP v1.1......................................................................................................................................118, 126
Hypertext Markup Language (HTML) v4.01...................................................................106, 110, 113
Hypertext Transfer Protocol (HTTP) v1.1.................................................................................118, 126
I
Identification Cards - Contactless integrated circuit cards.......................................................135
Identification Cards - Integrated circuit cards.............................................................................135
IMAP v4rev1.......................................................................................................................................125
Industrial Signature Interoperability Specification – MailTrusT (ISIS-MTT) v1.1.....................93
Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 1 to Part
6...........................................................................................................................................................125
Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 3........114
Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 7........136
Internet Message Access Protocol (IMAP) v4rev1........................................................................125
Internet Protocol (IP) v4...................................................................................................................124
146
SAGA 4.0
Internet Protocol (IP) v6...................................................................................................................124
Interoperability Specification for ICCs and Personal Computer Systems (PC/SC) v2.0..........136
IP v4.....................................................................................................................................................124
IP v6.....................................................................................................................................................124
ISIS-MTT v1.1........................................................................................................................................93
ISIS-MTT v1.1., Part 1 to Part 6...........................................................................................................125
ISIS-MTT v1.1., Part 3..........................................................................................................................114
ISIS-MTT379 v1.1, Part 7....................................................................................................................136
ISO 10646:2003..................................................................................................................................106
ISO 15836-2003....................................................................................................................................97
ISO 19005-1:2005...............................................................................................................................137
ISO 19125-2.........................................................................................................................................130
ISO/IEC 10746-3:1996..........................................................................................................................31
ISO/IEC 10918-1:1994...................................................................................................................115, 137
ISO/IEC 14443.....................................................................................................................................135
ISO/IEC-14496..............................................................................................................................116, 118
ISO/IEC 15444-1...................................................................................................................................116
ISO/IEC 15445.......................................................................................................................106, 110, 113
ISO/IEC 15948:2003...........................................................................................................................115
ISO/IEC 16262.....................................................................................................................................108
ISO/IEC 19503:2005......................................................................................................................96, 97
ISO/IEC 19757-2:2003..........................................................................................................................97
ISO/IEC 23270:2006............................................................................................................................99
ISO/IEC 23271:2006...........................................................................................................................100
ISO/IEC 26300:2006..............................................................................................................111, 112, 113
ISO/IEC 279001....................................................................................................................................83
ISO/IEC 7816.......................................................................................................................................135
ISO/IEC TR 23272:2006.....................................................................................................................100
ISO/PRF 19136......................................................................................................................................119
IT-Grundschutz-Vorgehensweise v1.0 [BSI standard 100-2: IT baseline protection approach]
...............................................................................................................................................................92
IT-Grundschutzkataloge [IT Baseline Protection catalogues].....................................................83
ITU-T.81........................................................................................................................................115, 137
J
J2EE Connector Architecture (JCA) v1.5.................................................................................122, 132
Java Database Connectivity (JDBC) v3.0.........................................................................................131
Java EE v5.............................................................................................................................................98
Java Language Mapping to OMG IDL.....................................................................................122, 132
SAGA 4.0
147
Java Message Service (JMS) v1.1.................................................................................................121, 132
Java Network Launching Protocol (JNLP) v1.5..............................................................................102
Java Platform, Enterprise Edition (Java EE) v5...............................................................................98
Java Platform, Standard Edition (Java SE) v5..................................................................................99
Java SE..................................................................................................................................................99
Java Server Pages (JSP) v2.1...............................................................................................................107
Java Servlet v2.5.................................................................................................................................107
JCA...............................................................................................................................................122, 132
JDBC.....................................................................................................................................................131
JMS................................................................................................................................................121, 132
JNLP.....................................................................................................................................................102
Joint Photographic Experts Group (JPEG)...............................................................................115, 137
Joint Photographic Experts Group 2000 (JPEG2000) / Part 1.......................................................116
JPEG..............................................................................................................................................115, 137
JPEG2000............................................................................................................................................116
JSP v2.1.................................................................................................................................................107
JSR-000054.........................................................................................................................................131
JSR-000056 (Final Release)..............................................................................................................102
JSR-000112...................................................................................................................................122, 132
JSR-000154 (Maintenance Release)................................................................................................107
JSR-000176...........................................................................................................................................99
JSR-000244..........................................................................................................................................99
JSR-000245.........................................................................................................................................107
JSR-000914...................................................................................................................................121, 132
K
Kerberos v5........................................................................................................................................105
KoopA ADV, Handlungsleitfaden für die Einführung der elektronischen Signatur und
Verschlüsselung in der Verwaltung v1.1 [Guideline for the Introduction of the Electronic
Signature and Encryption in the Administration]........................................................................94
L
LDAP v3...............................................................................................................................................130
Lightweight Directory Access Protocol (LDAP) v3.......................................................................130
M
Management systems for Information Security............................................................................91
Microsoft Windows .NET-Framework...........................................................................................100
MIME v1.0...................................................................................................................................106, 125
MP4...............................................................................................................................................116, 118
148
SAGA 4.0
MPEG-4 Part 14 (MP4).................................................................................................................116, 118
Multipurpose Internet Mail Extensions (MIME) v1.0...........................................................106, 125
O
OCF v1.2..............................................................................................................................................136
Office Open XML (OOXML)..................................................................................................111, 112, 113
Ogg...............................................................................................................................................117, 118
Ogg Encapsulation Format (Ogg)............................................................................................117, 118
Online Service Computer Interface (OSCI) Transport v1.2..........................................................127
OOXML...................................................................................................................................111, 112, 113
Open Document Format for Office Applications (OpenDocument) v1.0.....................111, 112, 113
OpenCard Framework (OCF) v1.2...................................................................................................136
OpenDocument v1.0............................................................................................................111, 112, 113
OSCI Transport 1.2.............................................................................................................................127
P
PC/SC...................................................................................................................................................136
PDF version 1.4......................................................................................................................110, 111, 112
PDF version 1.5......................................................................................................................110, 112, 113
PDF version 1.6......................................................................................................................110, 112, 113
PDF/A-1................................................................................................................................................137
PHP......................................................................................................................................................100
PHP Hypertext Preprocessor (PHP) v5.x........................................................................................100
PNG......................................................................................................................................................115
POP3....................................................................................................................................................125
Portable Document Format (PDF) v1.4..............................................................................110, 111, 112
Portable Document Format (PDF) v1.5.............................................................................110, 112, 113
Portable Document Format (PDF) v1.6.............................................................................110, 112, 113
Portable Document Format Archive - 1 (PDF/A-1).........................................................................137
Portable Network Graphics (PNG) v1.2...........................................................................................115
Post Office Protocol (POP) v3...........................................................................................................125
Q
Quicktime....................................................................................................................................116, 118
R
RDF.......................................................................................................................................................97
RealMedia v10.............................................................................................................................117, 118
Reference Model for Open Distributed Processing (RM-ODP69)................................................31
SAGA 4.0
149
Regular Language Description for XML New Generation (Relax NG)........................................97
Relax NG..............................................................................................................................................97
Remote Method Invocation (RMI)............................................................................................121, 131
Remote Method Invocation over Internet Inter ORB Protocol (RMI-IIOP) ..............................122
Resource Description Framework (RDF).........................................................................................97
RFC 1034/RFC 1035............................................................................................................................124
RFC 1510..............................................................................................................................................105
RFC 1700.............................................................................................................................................124
RFC 1939.............................................................................................................................................125
RFC 1945.............................................................................................................................................126
RFC 1952..............................................................................................................................................119
RFC 2045 to RFC 2049...............................................................................................................106, 125
RFC 2246.............................................................................................................................................127
RFC 2460............................................................................................................................................124
RFC 2518.............................................................................................................................................128
RFC 2616......................................................................................................................................118, 126
RFC 2821.............................................................................................................................................125
RFC 2965............................................................................................................................................126
RFC 3041.............................................................................................................................................124
RFC 3261.............................................................................................................................................126
RFC 3275..............................................................................................................................................114
RFC 3501.............................................................................................................................................125
RFC 3533.......................................................................................................................................117, 118
RFC 4251 - 4256..................................................................................................................................128
RFC 4346.............................................................................................................................................128
RFC 4510 - 4519..................................................................................................................................130
RFC 4810..............................................................................................................................................112
RFC 768...............................................................................................................................................124
RFC 791................................................................................................................................................124
RFC 793...............................................................................................................................................124
RFC 959..............................................................................................................................................126
Risikoanalyse auf der Basis von IT-Grundschutz v2.0 [BSI-Standard 100-3: Risk analysis on
the basis of IT baseline protection]..................................................................................................93
RM-ODP................................................................................................................................................31
RMI................................................................................................................................................121, 131
RMI-IIOP.....................................................................................................................................122, 132
Role models and flow charts............................................................................................................95
RSA...............................................................................................................................................132, 134
150
SAGA 4.0
S
SAML...................................................................................................................................................104
Secure Hash Algorithm (SHA)-224.................................................................................................134
Secure Hash Algorithm (SHA)-512..................................................................................................134
Secure Interoperable ChipCard Terminal (SICCT) v1.10..............................................................136
Secure Shell v2 (SSH-2)......................................................................................................................128
Security Assertion Markup Language (SAML) v2.0......................................................................104
Session Initiation Protocol (SIP) v2.0..............................................................................................126
SFA-2...................................................................................................................................................130
SHA-224..............................................................................................................................................134
SHA-256..............................................................................................................................................133
SHA-384..............................................................................................................................................134
SHA-512...............................................................................................................................................134
Short Message Services (SMS)..........................................................................................................120
SICCT..................................................................................................................................................136
Simple Feature Access – Part 2: SQL option (SFA-2) v1.1.0............................................................130
Simple Mail Transfer Protocol (SMTP)............................................................................................125
Simple Object Access Protocol (SOAP) v1.1.......................................................................121, 123, 131
SIP........................................................................................................................................................126
SMIL.....................................................................................................................................................113
SMS......................................................................................................................................................120
SMTP...................................................................................................................................................125
SOAP......................................................................................................................................121, 123, 131
SSH-2...................................................................................................................................................128
Synchronized Multimedia Integration Language (SMIL) v2.0...................................................113
T
Tagged Image File Format (TIFF) v6.0....................................................................................115, 137
Tape ARchive (TAR)...........................................................................................................................119
TAR.......................................................................................................................................................119
Technical guideline for federal-government eCard projects (BSI TR-03116) v1.0...................136
Text.......................................................................................................................................................111
TIFF...............................................................................................................................................115, 137
TLS v1.0................................................................................................................................................127
TLS v1.1................................................................................................................................................128
Transport Layer Security (TLS) v1.0.................................................................................................127
Transport Layer Security (TLS) v1.1..................................................................................................128
SAGA 4.0
151
U
UDDI....................................................................................................................................123, 124, 130
UML......................................................................................................................................................96
Unicode v4.x UTF-16.........................................................................................................................106
Unicode v4.x UTF-8...........................................................................................................................106
Unified Modeling Language (UML) v. 2.0.......................................................................................96
Universal Description, Discovery and Integration (UDDI) v2.0..................................123, 124, 130
UTF-16.................................................................................................................................................106
UTF-8..................................................................................................................................................106
W
WAP v2.0............................................................................................................................................120
WCS v1.0.............................................................................................................................................129
Web Coverage Service (WCS) v1.0.0...............................................................................................129
Web Feature Service (WFS) v1.0......................................................................................................129
Web Feature Service (WFS) v1.1.......................................................................................................129
Web Map Service Deutschland (WMS-DE) v1.0............................................................................129
Web Services (WS) Security v1.1.......................................................................................122, 123, 132
Web Services Business Process Execution Language (WS-BPEL) v2.0......................................100
Web Services Description Language (WSDL) v1.1...........................................................121, 123, 131
WebDAV.............................................................................................................................................128
WFS v1.0.0..........................................................................................................................................129
WFS v1.1.0...........................................................................................................................................129
Windows Media Video (WMV) v9............................................................................................117, 118
Wireless Application Protocol (WAP) v2.0....................................................................................120
WMS-DE.............................................................................................................................................129
WMV.............................................................................................................................................117, 118
WS-BPEL v2.0.....................................................................................................................................100
WS-Security........................................................................................................................122, 123, 132
WSDL.....................................................................................................................................121, 123, 131
WWW Distributed Authoring and Versioning (WebDAV)........................................................128
X
XAdES..................................................................................................................................................114
XForms v1.0........................................................................................................................................108
XHTML Basic v1.0..............................................................................................................................120
XHTML v1.0........................................................................................................................................107
XKMS...................................................................................................................................................134
XMI.................................................................................................................................................96, 97
152
SAGA 4.0
XML Advanced Electronic Signatures (XAdES) v1.2......................................................................114
XML Encryption.................................................................................................................................114
XML Key Management Specification (XKMS) v2..........................................................................134
XML Metadata Interchange (XMI) v2.x.....................................................................................96, 97
XML Schema Definition (XSD) v1.0...................................................................................................96
XML Signature...................................................................................................................................114
XML v1.0......................................................................................................................................109, 137
XML v1.1.......................................................................................................................................109, 138
XSD.......................................................................................................................................................96
XSL v1.0...............................................................................................................................................107
XSL v1.1................................................................................................................................................108
XSLT v1.0.............................................................................................................................................107
XSLT v2.0............................................................................................................................................108
Z
ZIP v2.0................................................................................................................................................119
SAGA 4.0
153
Appendix C Abbreviations
3DES
Triple Data Encryption Standard
AES
Advanced Encryption Standard
AG
Public limited company in Germany
APEC
Asia-Pacific Economic Cooperation
API
Application Programming Interface
ArchiSig
Conclusive and secure long-term archiving of electronically signed
documents
BGG
Law on equal opportunities for the disabled
BIT
Federal Office for Information Technology
BITV
Barrier-free information technology ordinance
BMI
Federal Ministry of the Interior
BMP
Windows Bitmap
BNetzA
Federal Network Agency for electricity, gas, telecommunications, post and
railways
BOL
2005 BundOnline Initiative
BPEL4WS
Business Process Execution Language for Web Services
BSI
German Federal Office for Information Security
CA
Certification Authority
CC VBPO
The "workflow management, processes and organization" competence
centre
CEN
Comité Européen de Normalisation
CMS
Content Management System
CORBA
Common Object Request Broker Architecture
CSIRO
Commonwealth Scientific and Industrial Research Organisation
CSS
Cascading Style Sheets Language
CSV
Character Separated Value
CSW
Web Catalogue Service
CTI
Computer Telephony Integration
DCMI
Dublin Core Metadata Initiative
DES
Data Encryption Standard
DIN
The German Institute for Standardization
154
SAGA 4.0
DNS
Domain Name System
DOMEA
Document management and electronic archiving in IT-based workflows
DRV
German Federal Pension Insurance
DSA
Digital Signature Algorithm
DSML
Directory Services Markup Language
DSS
Digital Signature Standard
DV
Data processing
DVDV
German Directory of Administrative Services
ebXML
Electronic Business using XML
ECMA
European Computer Manufacturers Association
OFA
One-for-all
e-GIF
E-Government Interoperability Framework
EJB
Enterprise JavaBeans
EML
Election Markup Language
ER
Entity Relationship
ERP
Enterprise Resource Planning
ETSI
European Telecommunications Standards Institute
EU
European Union
FinTS
Financial Transaction Services
FIPS-PUBS
Federal Information Processing Standards Publications
FLAC
Free Lossless Audio Codec
FMS
Formular Management System
FTP
File Transfer Protocol
G2B
Government to Business
G2C
Government to Citizen
G2E
Government to Employee
G2G
Government to Government
GDI-DE
Geo-data infrastructure Germany
GI
Gesellschaft für Informatik e.V.
GIF
Graphics Interchange Format
GML
Geography Markup Language
GSM
Global System for Mobile Communications
HTML
Hypertext Markup Language
SAGA 4.0
155
HTTP
Hypertext Transfer Protocol
HTTPS
Secure Hypertext Transfer Protocol
IANA
Internet Assigned Numbers Authority
IDABC
Interoperable Delivery of European eGovernment Services to public Admin
istrations, Businesses and Citizens
IEC
International Electrotechnical Commission
IETF
Internet Engineering Task Force
IIOP
Internet Inter-ORB Protocol
IMAP
Internet Message Access Protocol
IP
Internet Protocol
IPsec
Internet Protocol Security
ISIS
Industrial Signature Interoperability Specification
ISIS-MTT
Industrial Signature Interoperability Specification - MailTrusT
ISMS
Information Security Management System
ISO
International Organization for Standardization
IT
Information technology
ITG
Informationstechnische Gesellschaft im VDE
ITIL
IT Infrastructure Library
ITU
International Telecommunication Union
ITU-T
ITU Telecommunication Standardization Sector
IVBB
Berlin-Bonn Information Network
IVBV
Federal Administration Information Network
J2EE
Java 2 Platform, Enterprise Edition
JAAS
Java Authentication and Authorization Service
Java EE
Java Platform, Enterprise Edition
Java SE
Java Platform, Standard Edition
JAXP
Java API for XML Parsing
JCA
J2EE Connector Architecture
JDBC
Java Database Connectivity
JMS
Java Message Service
JMX
Java Management Extensions
JNDI
Java Naming and Directory Interface
JNLP
Java Network Launching Protocol
156
SAGA 4.0
JPEG
Joint Photographic Experts Group
JRE
Java Runtime Environment
JSP
Java Server Pages
JSR
Java Specification Requests
JTA
Java Transaction API
KBSt
Co-ordinating and Advisory Agency of the Federal Government for
Information Technology in the Federal Administration at the Federal
Ministry of the Interior
KoopA ADV
Co-operation Committee for Automatic Data Processing for the Federalgovernment, Federal-state Government and Municipal Administration
Sector
LDAP
Lightweight Directory Access Protocol
MAC
Message Authentication Code
MIME
Multipurpose Internet Mail Extensions
MIT
Massachusetts Institute of Technology
MOF
Meta Object Facility
MPEG
Moving Picture Experts Group
MTT
MailTrusT
NAT
Network Address Translation
NISO
National Information Standards Organization
NIST
National Institute of Standards and Technology
OASIS
Organization for the Advancement of Structured Information Standards
OCSP
Online Certificate Status Protocol
ODF
OpenDocument Format
OGC
Open Geospatial Consortium
OMG
Object Management Group
OOXML
Office Open XML
OSCI
Online Services Computer Interface
OSS
Open Source Software
PC
Personal Computer
PDA
Personal Digital Assistant
PDF
Portable Document Format
PDF/A
PDF Archive
PHP
PHP: Hypertext Preprocessor
SAGA 4.0
PIN
Personal identification number
PKCS
Public Key Cryptography Standards
PKI
Public Key Infrastructure
PKIX
IETF Working Group "Public-Key Infrastructure (X.509)"
PNG
Portable Network Graphics
POP
Post Office Protocol
PSE
Personal Security Environment
RDF
Resource Description Framework
Relax NG
Regular Language Description for XML New Generation
REL
Rights Expression Language
RFC
Request for Comments
RFP
Request for Proposals
RFID
Radio Frequency Identification
RIPE
RACE Integrity Primitives Evaluation
RIPEMD
RIPE (RACE Integrity Primitives Evaluation) Message Digest
RMI
Remote Method Invocation
RMI-IIOP
Remote Method Invocation over Internet Inter-ORB Protocol
RM-ODP
Reference Model of Open Distributed Processing
RSA
Rivest, Shamir, Adleman Public Key Encryption
SAGA
SAML
Security Assertion Markup Language
SC
Service Center
SFA
Simple Feature Access
SGML
Standard Generalized Markup Language
SHA
Secure Hash Algorithm
SIGA
Secure integration of eGovernment applications
SigG
German Digital Signature Act
SigV
Digital Signature Ordinance
SIP
Session Initiation Protocol
SLA
Service Level Agreement
SMIL
Synchronized Multimedia Integration Language
S/MIME
Secure Multipurpose Internet Mail Extensions
SMS
Short Message Service
157
158
SAGA 4.0
SMTP
Simple Mail Transfer Protocol
SOA
Service Oriented Architecture
SOAP
Simple Object Access Protocol
SQL
Structured Query Language
SSH
Secure Shell
SSL
Secure Sockets Layer
TAN
Transaction number
TAR
Tape Archive
TCP/IP
Transmission Control Protocol / Internet Protocol
TESTA
Trans-European Services for Telematics between Administrations
TIFF
Tagged Image File Format
TLS
Transport Layer Security
TMS
Travel Management System
Triple-DES
Triple Data Encryption Standard
UDDI
Universal Description, Discovery and Integration
UDP
User Datagram Protocol
UML
Unified Modeling Language
UN/CEFACT
United Nations Centre for Trade Facilitation and Electronic Business
URL
Uniform Resource Locator
UTF
Unicode Transformation Format
VDE
Association for Electrical, Electronic and Information Technologies
VLAN
Virtual Local Area Network
VM
Virtual Machine
VoIP
Voice over IP (IP telephony)
V-PKI
Administration Public Key Infrastructure (Administration PKI)
VPN
Virtual Private Network
W3C
World Wide Web Consortium
WAP
Wireless Application Protocol
WCAG
Web Content Accessibility Guidelines
WCS
Web Coverage Service
WebDAV
WWW Distributed Authoring and Versioning
WFS
Web Feature Service
WML
Wireless Markup Language
SAGA 4.0
WMS
Web Map Service
WMV
Windows Media Video
WS
Web Service
WS-BPEL
Web Services Business Process Execution Language
WSDL
Web Services Description Language
WS-I
Web Service Interoperability Organization
WS-Security
Web Services Security
WWW
World Wide Web
XadES
XML Advanced Electronic Signatures
XHTML
Extensible Hypertext Markup Language
X-KISS
XML Key Information Service Specification
XKMS
XML Key Management Specification
X-KRSS
XML Key Registration Service Specification
XMI
XML Metadata Interchange
XML
Extensible Markup Language
XÖV
XML-based technical standards for electronic data exchange within and
with the public administration.
XSD
Extensible Markup Language Schema Definition
XSL
Extensible Stylesheet Language
XSLT
Extensible Stylesheet Language Transformations
159

SAGA 4.0 - Bund.de

Transcription

Similar documents

TEXT (SMS) Marketing

register now! - Seattle Area German American School

Secret Norway brochure

BEYBLADE - Nelvana.com

EDITION 10.indd - East Lyme Public

Published Articles of JENESYS Program 2011 Jawa Pos

English version: “Inside and insight into Efteling”

MEDIEVAL SCANDINAVIA