SAGA 3.0 - IT-Beauftragter der Bundesregierung

Transcription

SAGA
Version 3.0
Standards and Architectures for
eGovernment Applications
KBSt publication
October 2006
KBSt publication
Reprint, even in part, subject to approval
This volume was prepared by the KBSt unit at the Federal Ministry of the Interior
in co-operation with ]init[ AG and
Fraunhofer-Institut für Software- und Systemtechnik (ISST).
Editor: ]init[ AG, Berlin
If you are interested in the KBSt publications currently available
or further information concerning the documents, please contact
Federal Ministry of the Interior
Unit IT 2 (KBSt)
11014 Berlin, Germany
Homepage and download of the digital version: http://www.kbst.bund.de/saga
mailto: IT2@bmi.bund.de
SAGA
Standards and Architectures for eGovernment Applications
Version 3.0
October 2006
Published by the
Word of thanks
The Co-ordinating and Advisory Agency of the Federal Government for Information Technology in the Federal Administration (KBSt) and the SAGA authors would like to thank the
representatives from the federal states and municipalities in the KoopA-SAGA project
group along with all the members of the SAGA expert group for their support during the
preparation of this SAGA version.
We would also like to extend our thanks to all those who made use of the SAGA forum and
the SAGA contact form and whose committed comments constituted a valuable contribution towards updating the document.
Preface:
This document presents in concise form standards, processes, methods and products 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, mostly English, acronyms. Some
of these names are protected by copyright and/or are registered trademarks, or are products of certain manufacturers or standardisation 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 acronym in this document does not mean that
they are free from copyrights or intellectual property rights of third parties.
Furthermore, neither the editor, authors or experts consulted can accept any responsibility
for the technical functioning, compatibility or completeness of the standards discussed.
This version 3.0 was published in October 2006. Please send any comments, amendments
or corrections to: Bundesministerium des Innern, Referat IT2 (KBSt). These comments,
amendments or corrections can also be published on the forum at: http://
www.kbst.bund.de/kbst_forum.
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 conformity is not enough in order to achieve the goals
of SAGA. Due to the complexity of the document, a general demand would leave 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 conformity, please refer to
section 2.4 on page 25, and for further assistance, go to: http://www.kbst.bund.de/sagakonformitaet.
Table of Contents
0
Status, revision history and outlook ............................................................ 9
0.1
1
Amendments to version 2.1 ................................................................................................. 9
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 ...........................................................12
1.6
Relationships with other eGovernment documents .................................................13
1.7
The evolution process ..........................................................................................................16
1.8
Structure ....................................................................................................................................17
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 .....................................................................21
2.4
SAGA conformity ....................................................................................................................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 ...................................................................................................33
3.5
Engineering viewpoint .........................................................................................................34
3.6
Technology viewpoint ..........................................................................................................34
4
Enterprise viewpoint: Fundamentals of eGovernment ............................ 35
4.1
Frame of reference for eGovernment in Germany .....................................................35
4.2
eGovernment applications .................................................................................................42
5
Information viewpoint: Data modelling and standardisation ................. 49
5.1
Background ..............................................................................................................................49
5.2
Information on data modelling .........................................................................................50
5.3
Standardisation of data models ........................................................................................52
6
Computational viewpoint: Reference software architecture ................... 55
6.1
General requirements for software applications ........................................................55
6.2
Implementation options and architecture paradigms .............................................57
page 7
6.3
7
Reference software architecture for eGovernment applications .........................61
Engineering viewpoint: Reference infrastructure .................................... 67
7.1
Design of an eGovernment infrastructure ....................................................................67
7.2
Network, users and external services ..............................................................................71
8
Technology viewpoint (part I): Standards for the IT architecture ........... 73
8.1
Process modelling ..................................................................................................................73
8.2
Data modelling .......................................................................................................................74
8.3
Application architecture ......................................................................................................76
8.4
Client ...........................................................................................................................................79
8.5
Presentation .............................................................................................................................82
8.6
Communication ......................................................................................................................94
8.7
Connection to the backend ............................................................................................. 100
8.8
Long-term archiving .......................................................................................................... 103
9
Technology viewpoint (part II): data security standards ....................... 105
9.1
Determining protection requirements ........................................................................ 105
9.2
Security concept .................................................................................................................. 106
9.3
Implementation of the security concept .................................................................... 108
9.4
Basic technology ................................................................................................................. 109
9.5
Applications .......................................................................................................................... 113
Appendix AOne-for-all offers ....................................................................................... 119
A.1
OFA service - Payment platform ("ePayment") ......................................................... 120
A.2
OFA service – Directory service ...................................................................................... 126
A.3
OFA servcie - GeoDataCentre (GDZ) ............................................................................ 129
A.4
OFA system - Data security ("virtual post office") .................................................... 133
A.5
OFA system - Form Management System (FMS) ..................................................... 141
A.6
OFA system – Content Management System (CMS) .............................................. 144
A.7
OFA system bund.de portal ............................................................................................. 150
A.8
OFA system - GeoPortal.Bund ........................................................................................ 156
A.9
Infrastructure - Federal Administration Information Network (IVBV) ............. 160
A.10 Administration Public Key Infrastructure ("V PKI") .................................................. 165
Appendix BBibliography .............................................................................................. 171
Appendix COverview of Classified Standards ............................................................. 173
Appendix DList of abbreviations .................................................................................. 177
page 8
0 Status, revision history and outlook
This document, version 3.0, is an authorised publication of Standards and Architectures for
eGovernment Applications (SAGA).
0.1
Amendments to version 2.1
This document is a revised version of SAGA, version 2.1. The following changes were made:
Chapter 2 "Fundamentals of SAGA" introduces minimum requirements for the openness of
standards to be included in SAGA1. The individual classifications are defined more strictly
and the transitions between classifications and lists in the lifecycle of standards are defined
more clearly2. A description is also given as to how the SAGA conformity of eGovernment
applications should be achieved3. This chapter also explains the preconditions under which
technologies which were not classified as "mandatory" can be used in a SAGA-compliant
manner 4.
Chapter 5 "Information viewpoint: Data modelling and standardisation" was completely
revised. First of all, different levels of interoperability were examined. This chapter provides
data model developers with assistance for their work. Finally, the progressive activities in
Germany's administration to standardise data models is dealt with in detail.
Chapter 6 "Computational viewpoint: Reference software architecture" introduces a service
oriented architecture (SOA) along with the component-based, four-level architecture for
systems which already exists. A three-level architecture is introduced for the implementation of services.
Chapter 8 "Technology viewpoint (part I): Standards for the IT architecture" now also features the topics of "Description language for metadata of files"5, "Geo-services"6 and "Longterm archiving"7. The file types for text, spreadsheets and presentations are now distinguished according to formats for information exchange and for processing8.
Chapter 9 "Technology viewpoint (part II): data security standards" was re-organized. A new
section was introduced for the topic of "Authentication"9. Asymmetric encryption
methods10 and hash functions11are now separately classified.
The former basic and infrastructure components are now described in Appendix A "Onefor-all offers" (OFA offers) as OFA services, OFA systems and infrastructure according to the
reference software architecture described in chapter 6. Business cases are no longer classi1. Refer to section 2.2 "Minimum requirements with regard to the openness of standards" on page 20
2. Refer to section 2.3 "Classification and life cycles of standards" on page 21
3. Refer to section 2.4.2 "SAGA conformity in invitations to tender" on page 27
4. Refer to section 2.4.3 "SAGA conformity despite low classification" on page 28
5. Refer to section 8.2.5 "Description language for metadata of files" on page 76
6. Refer to section 8.6.5 "Geo-services" on page 99
7. Refer to section 8.8 "Long-term archiving" on page 103
8. Refer to section 8.5.1.8 "Formats for text documents for exchanging information" on page 85
9. Refer to section 9.4.1 "Technologies for authentication" on page 109
10. Refer to section 9.4.6.1 "Asymmetric encryption methods" on page 112
11. Refer to section 9.4.5.1 "Hashing data" on page 111
page 9
fied. The former one-for-all services (OFA services) are now reorganized as services and systems outside SAGA on the KBSt homepage12.
Furthermore, the further development of standards has influenced this version of SAGA.
Standards were accepted from the White List, the classification of existing standards was
revised and some standards were moved from the document to the Grey List13.
Due to failure to meet with the latest minimum requirements for the openness of standards, Enhanced Compressed Wavelet (ECW) and MPEG-1 Layer 3 (MP3) were moved to the
Grey List. More open alternatives can be found in section 8.5.1.14 "Interchange formats for
graphics" on page 88 and section 8.5.1.16 "Interchange formats for audio and video files"
on page 90.
0.2
Future issues
The following topics are to be examined and dealt with in more detail in the next version of
SAGA:
a. Further promotion of SAGA conformity
b. Development and standardisation of process and data models
c. Further development of chapter 7 "Engineering viewpoint: Reference infrastructure"
with a view to the IT Infrastructure Library (ITIL)
In addition to the SAGA document, the Co-ordinating and Advisory Agency of the Federal
Government for Information Technology in the Federal Administration (KBSt) will offer
additional information, links and tools on its website.14
12. Refer to http://www.kbst.bund.de/
13. Both the White List and Grey List are defined in section 2.3.2 on page 22
14. Refer to http://www.kbst.bund.de/saga
page 10
1 Introduction
1.1
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 to ensure accessibility 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 supports work on this guideline. The latest developments and experience are being added to the document through
the discussion in the public SAGA forum. Meanwhile, version 3.0 also incorporates concrete
requirements of federal-state governments and municipalities which were drafted in close
co-operation with the KoopA-SAGA project group15. With this knowledge, the team of
authors regularly prepare an updated version with KBSt 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. When it comes to
planning and implementing IT projects, many federal agencies also make use of the onefor-all offers presented by SAGA and rely on this document in order to shape the interoperability of the different applications both planned and existing.
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 3.0, SAGA once again offers a guideline for the economic and futureorientated 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.
Application developers should feel free to seek further detail solutions whenever the standards presented herein are not sufficient for the implementation of technical requirements.
15. KoopA ADV = Co-operation Committee for Automatic Data Processing for the Federal Government, Federalstate Governments and Municipal Administration Sector
page 11
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 a media-consistent flow of information between citizens, business, the Federal Government and its partners
b. Reusability – Establishing process and data models for similar procedures when providing services and defining data structures
c. Openness – Integrating open standards into applications, refer to section 2.2 on
page 20.
d. Reduction of costs and risks – Considering investment-safe developments on the
market and in the field of standardisation
e. Scalability – Ensuring the usability of applications as requirements change in terms of
volume and transaction frequency
1.4
Tasks
SAGA pursues a comprehensive standardisation approach for Germany's administrations in
order to achieve these goals.
Defining technical Standards and Architectures for eGovernment Applications
The technical standards and architectures cover all the levels and components relevant for
eGovernment. They form the basis for the interoperability and compatibility of the eGovernment applications to be developed.
Standardising processes and data in administrations
In order to achieve interoperability and compatibility of eGovernment applications, it is
necessary to create a basis for standardising processes and data in Germany's administrations. In an effort to support this, systems and services are also described which can be used
as modules (e.g. one-for-all offers) in eGovernment applications.
1.5
Basic principles for eGovernment applications
Modern eGovernment calls for information and communication systems which ideally
interact smoothly. The simple, clear-cut standards and specifications identified by SAGA
help to achieve the interoperability of information and communication systems.
eGovernment applications are developed in accordance with the following basic principles:
a. eGovernment applications primarily use the browser as the front-end, unless the services to be implemented cannot be reasonably handled via a browser.
page 12
b. They do without active contents in order to avoid forcing users to reduce the browser's
security settings which could lead to damage caused by unsafe websites. If active content is necessary, only signed and quality-secured applications of the type contemplated in section 8.4.1 "Web-based / computer-based access to information" on page 80
are used.
c. eGovernment applications do not store any program parts or data on the users' computers beyond the users' control16.
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 countries17. 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", the "Migration Guide" and the "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.
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 eGovernment manual is prepared under the leadership of the German Federal Office for Information Security18. This manual is designed as a reference
manual and central information exchange for issues related to eGovernment.
The 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 eGovernment
manual does so in a more concrete manner. This is why certain modules of the eGovernment manual are referenced from within SAGA19. SAGA sets forth guidelines, whilst the
eGovernment manual explains the implementation of these guidelines and gives practical
advice.
In mid-February 2003, SAGA became part of the 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 "Secure integration
of eGovernment applications (SIGA)"20 is being presented. The aim of this study is to adapt
16. One negative example of unrequested storing of programs on computers is the automatic installation of software which takes place when some music CDs are inserted
17. Refer to the respective documents and publications in the UK [e-GIF], the United States of America [FIB-PUBS],
Austria [APEC] and Europe [IDABC].
18. Refer to http://www.bsi.bund.de/fachthem/egov/3.htm
19. Refer, for instance, to section 9.1.2 on page 106, section 9.2 on page 106 and section 9.4.1 on page 109
20. Refer to http://www.bsi.bund.de/fachthem/egov/4_siga.htm
page 13
the technologies presented in SAGA for the middle tier level, to uncover correlations and to
provide decisive, independent assistance for IT experts and decision makers.
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 baseline protection document21.
The aim of these 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 baseline protection includes the BSI standards for IT security management22 and the IT
baseline protection catalogues23 which replace the previous IT Baseline Protection Manual.
The BSI standards are broken down into:
a. BSI standard 100-1: Management systems for Information Security (ISMS)24,
b. BSI standard 100-2: IT baseline protection approach25 and
c. BSI standard 100-3: Risk analysis on the basis of IT baseline protection26.
The application of IT baseline protection is supported in SAGA; the BSI standards for IT
security management and the IT baseline protection catalogues are defined as mandatory
standards27.
The barrier-free information technology ordinance – BITV
The ordinance on the creation of barrier-free information technology pursuant to section
11 of the law on equal opportunities for the disabled (barrier-free information technology
ordinance – BITV)28 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 layers29.
V model
The procedure model ("V-Model") is the development standard for IT systems (EStdIT) with
binding effect for the entire area of federal administration. This model 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
21. Refer to http://www.it-grundschutz.de/
22. Refer to http://www.bsi.de/literat/bsi_standard/
23. Refer to http://www.bsi.de/gshb/deutsch/
24. Refer to http://www.bsi.bund.de/literat/bsi_standard/standard_1001.pdf
25. Refer to http://www.bsi.de/literat/bsi_standard/standard_1002.pdf
27. Refer to chapter 7 on page 67 and section 9.2 on page 106
28. Refer to http://bundesrecht.juris.de/bitv/
29. Refer to section 4.1.5.3 on page 41 and section 8.5.1.1 on page 82
page 14
the same time, it describes the concrete approach with which these results are to be achieved. Furthermore, the V model 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 latest version is V model XT30. New releases will be issued and with the involvement of
all participants, this model will continue to be developed further.
Migration guide
The Migration guide31 is designed to offer both strategic/economic and detailed technical
decision-making aids for forthcoming or recently completed migration projects. The focus
of this guide is the replacement of Microsoft products both with open-source software
(OSS) as well as future generations of Microsoft products. Agency-specific scenarios are
developed and different migration alternatives are discussed.
The migration guide was developed with a view to SAGA version 2.1 in as far as relevant
interfaces were concerned. SAGA updates will have no repercussions on the statements
made.
The DOMEA concept
DOMEA32 stands for "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 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.
30. Refer to http://www.kbst.bund.de/v-modell
31. Refer to http:/www.kbst.bund.de/migrationsleitfaden
32. Refer to http://www.kbst.bund.de/domea
page 15
1.7
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 or the SAGA authors
b. Examination of proposals by the SAGA authors
c. Discussion in the 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 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 KBSt33 and within the scope of the eGovernment Manual34.
If problems occur that cannot be resolved using known standards, requests for proposals
are sent to the expert group in order to explore possible solutions.
The proposals put forward to the SAGA authors in the public forum, in the contact form and
in the expert group will be listed in future in a KBSt SAGA report and the result of the examination is documented. The reasons for acceptance or rejection are explained.
Public discussion forum
A public forum at: http://www.kbst.bund.de/kbst_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 form35 for SAGA users. This form can be used to
send structured ideas and queries directly to the SAGA authors.
Expert group
The KBSt has established an expert group36 comprising representatives from business, science and administration and appoints the members. The expert group is involved in the
updating process at regular intervals or whenever there is reason for involvement.
33. Refer to http://www.kbst.bund.de/saga
35. Refer to http://www.kbst.bund.de/saga-antragsformular
36. Refer to http://www.kbst.bund.de/saga-expertenkreis
page 16
1.8
Structure
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 classifications 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 9 present viewpoints of 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 standardised processes (enterprise viewpoint).
b. Chapter 5 describes activities for defining standardised data models (information viewpoint).
c. Chapter 6 introduces a reference software architecture as a basis for developing
architectures for concrete eGovernment applications (computational viewpoint).
d. In Chapter 7, the requirements for eGovernment computing centres and the inclusion
of modules, such as one-for-all offers, are presented in an existing infrastructure (engineering viewpoint).
e. Chapters 8 and 9 define the SAGA standards for the IT architecture and for ensuring
data security and integrity (technology viewpoint).
Appendix A gives a detailed description of the one-for-all offers which were largely developed during the BundOnline 2005 Initiative. Contact information, the functionality with concrete cases (application scenarios), interfaces, information regarding operation, reference
projects and an outlook are also presented in addition to these offers.
Appendix B contains a list of references and Appendix C provides an alphabetic list of the
standards referred to in Chapters 8 and 9. Appendix D then presents a list of abbreviations
used in SAGA.
page 17
page 18
2 Fundamentals of SAGA
2.1
Scope of validity and binding effect of SAGA
There are three target groups37 for the Federal administration's services, refer to the selection shown in Figure 2-1:
a. Citizens (Government to Citizens – G2C)
b. Companies (Government to Business – G2B)
c. Administration (Government to Government – G2G)
G2C
Government to Citizens
• BA: Job exchange
• BfA: Calculation and payment
of pensions
• BMAS: Provision of
information
• DWD: Weather forecasts and
meteorological advice
• BpB: Provision of information
and order handling
G2B
Government to Business
• BA: Job exchange
• BeschA: Procurement
• BBR: Procurement for
construction and civil
engineering projects
• BMBF: Project-related
subsidies
• BMWi: Subsidy programmes
G2G
Government to Government
• KBA: Central traffic and motor
vehicle registers
• BBR: Procurement for
construction and civil
engineering projects
• BMF: Management of Federal
Government properties
• BAköV: Further training and
education
• BZR: Federal Central Register
of Criminal Offences
Figure 2-1: Selected Federal Government services
Around 400 services were identified for the different federal administrations. An analysis of
the services along the value chain made it possible to identify eight service types38. 73 percent of the services used today belong to the three following types:
a. Capturing, processing and providing information
b. Processing applications and requests sent to an administration office
c. Processing subsidy and assistance applications
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 contains recommendations for standards and architectures for eGovernment applications. eGovernment applications are software systems that are used to perform Federal
Government services or which actively support the performance of such services. In the
case of systems with no direct interfaces with eGovernment, migration is recommended on
condition that the outcome of a cost-to-benefit analysis is positive. The standard soft37. For a more detailed explanation, refer to section 4.2.1.2 "Interaction relations" on page 42
38. Refer to [BOL], page 20
page 19
ware39 to be used should, whenever possible, be primarily products or product versions
which are compatible with SAGA recommendations.
Standards or architectures not listed in SAGA:
a. are not specific to 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.
Furthermore, SAGA considers only those areas which have a major influence on the aforementioned objectives rather than all the elements of a technical architecture.
When inviting tenders for eGovernment applications for the federal administration, the
KBSt recommends that SAGA be considered in the manner described in section 2.4.1 "Definition of conformity" on page 25 and section 2.4.2 "SAGA conformity in invitations to tender" on page 27.
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 to promote 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
standardisation 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 standardisation 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 has been published and the standard specification document is available
either freely or at a nominal charge.
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.
39. Software that is simply installed and configured
page 20
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 listed
should not be used or only if absolutely unavoidable; refer also to section 2.3.2 "Extended
classification of standards" on page 22.
Under Observation:
Standards are under observation if they are in line with the intended development trend,
are finalised and meet the minimum requirements for the openness of standards40. These
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
standards under observation, such standards under observation can be used in eGovernment applications. Only in justified exceptional cases should standards under observation
be given preference 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;
refer to section 1.3 "Aims" on page 12. 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 core
applications. 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
40. Refer to section 2.2 "Minimum requirements with regard to the openness of standards" on page 20
page 21
of SAGA; refer to section 1.3 "Aims" on page 12. Such standards must be observed and
applied with priority.
Competing standards can be mandatory parallel if they have clearly different core applications. 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. recommended standards and 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 has to 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
In the SAGA section on the website of the Co-ordinating and Advisory Agency of the
Federal Government for Information Technology in the Federal Administration at: http://
www.kbst.bund.de/saga-standards, three lists for extended classification of standards were
introduced with the publication of SAGA 2.0. No standards other than those on the grey list
may be given preference over the standards classified in the SAGA document (mandatory,
recommended, under observation) – however, only if existing systems, in which these standards are already in use, are being upgraded.
White List
The White List was created in order to respond promptly to new developments and in order
to be able to communicate these externally. During the course of developing the SAGA
document further, the White List is an important basis for including standards in SAGA.
Standards are listed in the White List if proposals for their inclusion in SAGA were submitted
to the SAGA authors, if they have potential for use in eGovernment applications and if
these standards were not yet classified further.
Standards in the White List are evaluated by the SAGA authors and the expert group. The
result of this evaluation can mean acceptance of the standards in the next version of the
SAGA document, relocation to the Black List or also remaining on the White List, so that
development can be observed, for instance, in the case of standards not yet finalised.
Before a new version of SAGA is being published, the standards on the White List are again
examined with regard to their suitability for inclusion.
Grey List
Standards are added to the 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, are no longer to be used for new eGovernment applications.
page 22
Black List
Within the scope of the SAGA discussion, certain standards that were already rejected in
the past are repeatedly proposed for inclusion. The 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 Black List if they were examined and rejected by the SAGA
authors and the expert group. The standards should not be used in new or existing eGovernment applications. Their use is only permitted if a parallel SAGA-compliant solution
exists. Images, for instance, can be made available in BMP format even though this is on the
Black List, if images are also offered at the same time in a SAGA-compliant format such as
GIF.
If a standard on the Black List is developed further and differs from the old version in areas
that were previously criticised, the version number of the black-listed standard must be stated. Now nothing stands in the way of the new version being included in SAGA via the
White List.
2.3.3 Life cycles of standards
Besides the standards classified in SAGA, refer to section 2.3.1 on page 21, other standards
are recorded in three different lists, refer to section 2.3.2 on page 22. 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 in the SAGA section of the website of the Co-ordinating and Advisory Agency of the Federal Government for Information Technology in the Federal Administration at: http://www.kbst.bund.de/saga-standards.
Standards can pass through different stages during their life cycle. This is illustrated in
Figure 2-2 "Lifecycles of SAGA standards" on page 24.
The transitions of a standard between the lists in the SAGA section at: http://
www.kbst.bund.de/saga-standards and the classes in the SAGA document are defined in
the following section.
page 23
SAGA section on
the KBSt website
SAGA document
Black list
Mandatory
rejected,
obsolete standards
9
5
6
8
Recommended
7
Grey list
Standards to be
maintained in effect
2
4
White list
Under observation
3
new standards not yet
classified
1
New standards
Figure 2-2: Lifecycles of SAGA standards
1
New standards are proposed for classification by the SAGA authors or by users;
refer to section 1.7 "The evolution process" on page 16. Without any further indepth examination, these standards are initially compiled in the White List. A thorough examination is carried out before a new SAGA version is created. Apart from
the transfer to the SAGA document or the Black List, the examination may result in
the standard remaining on the White List. Such standards do not yet fulfil the
requirements for inclusion in SAGA, e.g. because they are not yet finalised. 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
Black List as rejected standards.
3
Following a positive examination of the respective requirements, refer to
section 2.3.1 "Classification in SAGA" on page 21, 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 3 and 4 or 3, 4 and 5, respectively,
are then carried out in one step.
page 24
4
Following successful examination of the respective requirements in SAGA, standards with "under observation" status are classified as "recommended" in the next
SAGA version. If the requirements are fulfilled, the standard can also be directly
allocated to the higher class, i.e. "mandatory". Transitions 4 and 5 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
Black List retain the "under observation" classification.
5
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 Grey List retain the "recommended"
classification.
6
Following examination and the respective re-evaluation in SAGA, standards with
"mandatory" status are classified as "recommended". If the standard is no longer to
be used in new projects, it can be immediately transferred to the Grey List. Transitions 6 and 7 are then carried out in a single step. Standards which after examination
continue to meet the requirements for classification as "mandatory" maintain their
status.
7
If, after in-depth examination, standards with "recommended" status are not to be
used any longer in new projects, these standards are transferred to the Grey List
and are maintained in effect.
8
Obsolete standards in the Grey List which were kept sufficiently long in the Grey
List and which are not to be maintained any longer are transferred to the Black List.
9
Standards with "under observation" status which no longer have any chance of
ever being transferred into a higher classification are directly transferred to the
Black List.
The standards which are examined with 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.
2.4
SAGA conformity
2.4.1 Definition of conformity
The SAGA conformity of an eGovernment application41 is evaluated on the basis of the
models, procedures and standards described in SAGA:
a. Consideration of standardised process models
b. Consideration of standardised data models
41. The term "eGovernment application" is used as the 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 on page 35.
page 25
eGovernment application
Com ponent 1
(in-house
developm ent)
Com ponent 2
(product)
...
Com ponent n
(...)
Check-list for
com ponents
dev eloped in-house
Check-list for
product
com ponents
...
Check-list for
...
Figure 2-3: Layout of the SAGA declaration of conformity and checklists
c. Compliance with the standards and architectures described in SAGA
d. Use of existing one-for-all offers (OFA offers)
In order to enable a comprehensive statement concerning the SAGA conformity of an eGovernment application – especially in conjunction with the implementation of complex, specialised processes – an application should first be broken down into individual components42 before evaluating its conformity. A distinction is made here between in-house
developments and product components. In order to evaluate the SAGA conformity 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 KBSt homepage provides a blank and an example of a completed declaration of conformity with checklists for components developed in-house and for product components43. The checklists feature topical areas which are relevant for in-house developments or
for products, respectively.
Which specific standards from the relevant topical areas have to be used to ensure SAGA
conformity 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 conformity if these terminal devices are to be used
by the eGovernment application. SAGA conformity is hence achieved by applying the particular subset of all SAGA standards which is relevant for the specific eGovernment application.
42. When it comes to the SAGA conformity of eGovernment applications, components are understood to be nontrivial, self-contained, exchangeable modules of an eGovernment application which have a clearly defined
function within the context of the overall application architecture and which have interfaces. Complex components can be broken down into other components.
43. Refer to http://www.kbst.bund.de/saga-konformitaet
page 26
2.4.2 SAGA conformity in invitations to tender
In order to avoid neglecting the customer's concrete requirements when it comes to SAGA
conformity and in order to avoid having to exclusively rely on statements by the supplier,
the customer should include a section on "SAGA conformity" criteria in its contracting
documents.
A general demand for SAGA conformity 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 conformity may be made.
Instead, the declaration of conformity process described below should be applied by the
customer and the supplier. This process limits the room for interpretation and reduces mistakes. 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 helps
prevent offers from becoming unnecessarily expensive for both sides.
This process essentially comprises five steps:
Step 1: Including SAGA conformity 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 KBSt homepage can serve as a template44. 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 conformity criteria group within the scope of offer preparation
The supplier responds to the "SAGA conformity" 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 KBSt homepage45. This criteria group is filled in, it serves as an
example and contains explanatory comments which are helpful when filling in a concrete
criteria group.
page 27
Step 3: Supplier examination of the details concerning SAGA conformity, 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 conformity" criteria group, i.e. which
cannot warrant "SAGA conformity" are evaluated accordingly.
Step 4: Supplier completion of the declaration of conformity for the completed application
If the supplier has implemented the eGovernment application, he declares the SAGA conformity of the application in writing. To do so, he completes the declaration of conformity
for the application and attaches the checklists for the individual components of the application. Deviations from the commitments made in the completed "SAGA conformity" 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 conformity. The supplier can refer
to the sample declaration of conformity that can be downloaded from the KBSt homepage46. Blank templates of a declaration of conformity are also available on this homepage.
Step 5: Examining SAGA conformity on the basis of the offer and the declaration of conformity
by the supplier within the scope of acceptance
During acceptance, the customer can evaluate SAGA conformity on the basis of the "SAGA
conformity" criteria group completed by the supplier in the offer and the declaration of
conformity 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 conformity despite low classification
A SAGA-compliant 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 conformity47.
A lack of alternatives
The use of recommended standards is SAGA compliant if no mandatory alternatives exist.
Standards "under observation" can also be used and are SAGA compliant if no mandatory
or recommended standards are listed in SAGA for the respective application purpose.
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 are to be
47. Refer also to the definitions for classification and lists on the web in section 2.3 on page 21
page 28
given preference. The reasons for this are, first and foremost, when extended functionality48 is required, or special areas of application49. 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 may already be featured on the Black List.
Parallel offers
If SAGA-compliant 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 data50 is made available in CSV format, the same data can additionally be made available in other formats, such as Microsoft Excel, without violating SAGA
conformity.
Use of product components
In the case of product components (in contrast to components 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 offers do not form part of the checklists for the SAGA declaration of conformity. In the
case of certain components, customers should check whether to nevertheless specify the
corresponding technologies in order to make use, for instance, of existing infrastructures
for operating components 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 conformity of an eGovernment application.
2.4.4 Responsibility for conformity
The public agency responsible for an eGovernment application is also responsible for ensuring conformity with SAGA. The public agencies are also responsible for examining ways to
migrate their applications.
The federal ministries lay down rules for responsibility within their areas of competence.
Due to the complexity of SAGA, the process of securing SAGA conformity 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 KBSt's SAGA homepage51 .
48. Refer, for instance, to the descriptions of the different PDF versions in section 8.5.1.8 on page 85
49. Refer, for instance, to the descriptions of Unicode encoding in section section 8.5.1.4 "Character sets" on
page 83
50. Refer to section section 8.5.1.11 "Formats for spreadsheets for further processing" on page 87
page 29
2.4.5 Migration for conformity
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 version may temporarily not comply with the current
SAGA version.
Migration plans should be developed for non-compliant applications if the result of the
cost-to-benefit analysis is positive. This may only be the case where a major enhancement
of the application is concerned.
Measures to achieve conformity
The following measures are designed to support conformity with SAGA:
a. SAGA is included in project planning processes at an early stage.
b. Conformity with SAGA is specified and checked when projects are approved.
c. Conformity with SAGA can be a mandatory criterion for projects subsidised by public
administrations.
d. SAGA conformity is specified as a mandatory criterion for government contracts.
2.4.6 Non-conformity
eGovernment applications which are, as a whole or in part, non-compliant with SAGA are
subject to the following restrictions:
a. The use of one-for-all offers (OFA offers) 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. In most cases, no subsidies are available from public administrations.
page 30
3 Architecture model for eGovernment applications
3.1
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 of Open Distributed Processing (RM-ODP52) is the approach of choice
for describing complex, distributed eGovernment applications. The analysis of the application is broken down into different viewpoints in order to reduce the complexity of the overall architecture. This makes the demanding system easier to understand and hence better
to handle. The object-orientated paradigm is the basis of RM-ODP. Object orientation promotes clear-cut structures, re-usability and updating capability of both the models created
and of system.
The RM-ODP model defines five viewpoints of a system (refer to Figure 3-1):
Enterprise
viewpoint
Information
viewpoint
Computational
viewpoint
Process models
and roles
eGovernment
Data and data
modeling
Hardware and
infrastructure
Modules and
interfaces
Standards and
techniques
Engineering
viewpoint
Technology
viewpoint
Figure 3-1: Viewpoints according to RM-ODP
52. Reference Model of Open Distributed Processing, refer to [ISO 1996]
page 31
a. The enterprise viewpoint specifies the aims, scope, processes and policies 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 modules 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
eGovernment applications.
Furthermore, the SAGA document itself is structured according to the RM-ODP model. This
is how the chapters were designed and can be assigned to a viewpoint; refer to section 1.8
"Structure" on page 17.
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" (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 homepage provides a guideline for data and process modelling and supports
those in charge during process modelling. Support is also available from the competence
centre "workflow management, processes and organization" (WMPO CC)53 .
53. Refer to http://www.kbst.bund.de/Content/Egov/Ccvbpo/ccvbpo__inhalt.html
page 32
Chapter 4 "Enterprise viewpoint: Fundamentals of eGovernment" on page 35 describes the
enterprise viewpoint of German eGovernment as a model. In section 8.1 "Process modelling" on page 73, 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 homepage provides a guideline for data and process modelling and supports
those in charge during data modelling.
Chapter 5 "Information viewpoint: Data modelling and standardisation" on page 49 corresponds to the information viewpoint of German eGovernment and should be considered
when creating data models. Section 8.2 "Data modelling" on page 74 classifies the technologies to be applied.
3.4
Computational viewpoint
This viewpoint breaks an application down into logical, functional modules which are suitable for distribution. The result is objects with interfaces at 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 modules. Secure interaction may be required here. The protection goals are described in
section 9.1.1 on page 105.
The applications are also broken down into layers in which each of the individual modules
can be found.
Chapter 6 "Computational viewpoint: Reference software architecture" on page 55 gives 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 for different application cases with eGovernment
applications, such as systems and services. In sections 8.3 to 8.7 on page 76 and following,
SAGA defines standards and technologies for implementing the computational viewpoint.
Chapter 9 on page 105 defines standards and models for secure interaction.
page 33
3.5
Engineering viewpoint
The engineering viewpoint describes the system support needed to permit the distribution
of objects from the computational viewpoint. This includes units where objects are executed, such as computer hardware and communication infrastructures, as well as all kinds
of software platforms for distributed systems.
Chapter 7 "Engineering viewpoint: Reference infrastructure" on page 67 gives a general
description of the engineering viewpoint for federal-agency eGovernment applications.
The corresponding viewpoint of a concrete online service can be derived from this.
Chapter 9 on page 105 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 73, SAGA describes the classified standards for the IT architecture.
Models and standards that are relevant for and support safety and security are specified
separately as general-interest issues in chapter 9 on page 105 for all areas of the IT architecture.
page 34
4 Enterprise viewpoint: Fundamentals of eGovernment
In line with the definition of the enterprise viewpoint, the fundamentals of eGovernment in
Germany will be described in the following as the overall environment for the standardised
introduction of eGovernment applications.
Besides this general approach, the process level 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
Frame of reference for eGovernment in Germany
4.1.1 Definition of eGovernment
The term eGovernment has many different meanings. Many people regard eGovernment
as just another buzzword of the computer age, whilst others consider it to be the next logical step in administrative IT or as the electronic manifestation of the attempts so far made
to reform the administration.
The BundOnline initiative, concluded in 2005, sees eGovernment as being all processes
which serve decision-making and services in politics, government and administration and
which use information and communication technologies. The possibilities offered by these
technologies are very diverse. They range from the modernisation of administrative processes using electronic workflow management via the provision of administrative information
using public agency portals on the Internet right through to complex transactions and
interactive electronic web services for citizens. The aim is to afford external users of administration services, i.e. citizens, businesses and the administration itself, electronic access to
administration services and information.
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. As
far as eGovernment is concerned, citizens are the addressees 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 Definition of the "service" term
The term "service" must first be defined in order to understand certain forms of administrative action as services for the purposes of eGovernment. A "service" is generally rendered
against payment of a fee. Within the framework of the BundOnline Initiative, the term "service" was defined for the field of eGovernment. When citizens and businesses contact
government, "service" then refers to the complete performance of a process for the citizen
or business in question. A service includes processes, obligations and burdens, such as
recognition as a conscientious objector, applications for unemployment benefits or the
granting of an import permit. For the purposes of the following discourse, the term "ser-
page 35
vice" will hence cover any contacts between citizens or businesses on the one hand and the
administration on the other54.
4.1.3 The philosophy underlying e-government
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 other55.
4.1.3.1
Citizens' service
The Internet and networked computer systems are shaping the future. This can be seen, for
instance, in the high number of young Internet users. The growing penetration of the Internet into society is also leading to a growing demand for electronic services by governments. eGovernment can meet 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 the 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 shape citizens' service to meet demand, citizens must remain free to choose
which access to the administration they wish to use. Personal contact with the administration, e.g. via citizens' offices, must continue to be possible, i.e. access to the public administration must be possible, either in person, via the Internet and e-mail and per telecommunications. These access channels must be integrated as early and as far as possible internally
and processed in a standardised 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.1.3.2 eGovernment as a location factor
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 customs and tax administration.
On a global scale, all leading industrialised nations introduced powerful eGovernment services in recent years. eGovernment is today a location factor. The national 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 demand54. Refer also to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter VI 1, module
"E-government glossary“, section 1.2
55. Refer also to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter I, module
"Chefsache E-Government – Leitfaden für Behördenleiter" (E-government as an executive task – a guide for
heads of public administrations)
page 36
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.
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, barriers for companies must be kept as low as
possible. This approach is being pursued, for instance, by the strategy of DeutschlandOnline56, the Federal Government's eGovernment programme up to the year 201057, eGovernment initiatives by the federal states and the XÖV projects58 .
4.1.4 Organizational requirements
The successful implementation of eGovernment requires legal and organizational
boundary conditions. The most important of these requirements are described in the following sections.
4.1.4.1
The cross-administration approach
Countries with a federal structure are faced with the problem of de-centralised administration when it comes to the implementation of eGovernment. The de-centralised administrative units are often largely independent of central government. This situation is particularly
striking in Germany. 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 has only a few national tasks. Only those functions specifically defined in the German Constitution (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
specialised administrative agencies which are responsible for the entire German territory
and which have no other underlying administrative structures. These include, for instance,
the Federal Criminal Police Office, the Federal Statistical Office as well as the German Patent
Office.
The immediate federal administration consists of:
a. 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. Superior federal authorities with central responsibility for a particular field for the entire
Federal Republic of Germany (for example, the German Federal Cartel Office)
c. Intermediate-level federal authorities with regional responsibility (e.g. the different
regional finance offices)
56. Refer to http://www.deutschland-online.de/
57. Refer to http://www.bmi.bund.de/
58. Refer to http://www.xoev.de/
page 37
d. Lower-level federal authorities with locally restricted activities (for example, main customs offices)
The Federal Government commissions external administrative bodies as independent legal
entities with regard to certain federal-state tasks related to law enforcement. 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
communities with autonomous administrations which also perform their own tasks in addition to federal and federal-state functions.
What is generally needed is co-operation, networking and co-ordination within and between administrative levels. A first step that was taken at federal level was the implementation of the Berlin-Bonn Information Network (IVBB) which is an intranet for supreme federal
authorities. By upgrading this network to the Federal Administration Information Network
(IVBV), it will connect all the federal authorities to a secure, closed network – an enormous
challenge both technically and in terms of organization59.
The users of eGovernment services usually do not differ with the administration levels of
government, federal states and municipalities. Instead, companies and citizens tend to
expect standardised and consistent eGovernment services. With Deutschland-Online as the
joint national eGovernment strategy by the federal government, the federal states and
municipalities, an expanded action plan was presented in June 200660. This strategy
assigns priorities to joint projects, for example, in the field of citizens' registers, civil status
registers, vehicle registers and the expansion of the national communication infrastructure
of Germany's administration.
4.1.4.2 Process optimisation
The successful introduction and implementation of eGovernment calls for the examination
of grown processes. Existing rules, processes and structures must be adapted and simplified. The mere electronic implementation of conventional procedures seldom leads to
optimisation.
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 applications are implemented electronically.
a. Simplification of processes and procedures
b. Deregulation
c. Shortening of process chains
d. Reduction in the number of interfaces
59. Refer also to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter V C, module
"Network platform for eGovernment"
60. Refer to http://www.deutschland-online.de/
page 38
e. Avoiding iteration
f.
Reducing cycle and dead times61
First steps towards reducing red tape were designed to simplify processes and legal regulations for administration services. This was why Deutschland-Online covered services that
concerned several administration levels. The Federal Government's "Future-orientated
administration through innovation"62 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.1.4.3
Qualification of personnel
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.
4.1.4.4
Involvement of users
The use of eGovernment is strongly dependent on customer acceptance of the services
offered. Full utilisation 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.1.5 Legal frame of reference
Legal guidelines must be considered in addition to the organizational frame of reference.
The most important of these requirements are described in the following sections. A
detailed description of the legal adjustments carried out can be found in the Federal
Government's eGovernment manual63.
4.1.5.1
Electronic signatures
Users of eGovernment applications can authenticate themselves using electronic signatures64. Modern eGovernment accordingly requires the timely adaptation of legal foundations, so that media inconsistencies can be avoided and efficient, paper-less administrative
work enabled.
61. Refer also to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter III, module
"Phase 3 – analysis"
62. Refer to http://www.verwaltung-innovativ.de/
63. Refer also to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter II, module
"Legal frame of reference for eGovernment"
64. Refer to section 9.4.1 "Technologies for authentication" on page 109, section 9.4.3 "Connecting smartcards"
on page 110 and section 9.4.5 "Electronic signature" on page 111
page 39
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. 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
German Signature Act to comply with European requirements, the electronic signature has
also been integrated into the relevant blanket clauses in administrative and private law65.
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 benefit and costs. For instance, qualified electronic signatures are only used up to now in a few mass processes and administration areas, e.g. in invoicing. The reasons for this are the lack of interoperability between different signature card applications and the legal recognition which is restricted to a few
individual states. The costs involved in reorganizing internal administrative procedures,
installing the technology (chipcards, software, card readers) and ongoing use (certification
of the signature key which must be repeatedly certified) are still relatively high. In addition
to this, there is still a need for clarification with regard to the use and added value of electronic signatures among citizens.
Due to a resolution by the federal cabinet on 9 March 2005 concerning the main elements
of a joint eCard strategy by the Federal Government to support the nation-wide introduction of electronic cards, the use of electronic signatures can be expected to increase in the
future. This resolution foresees that card projects by the federal administration – the electronic health insurance card, the electronic ID card, JobCard procedures and the electronic
tax return – will be closely co-ordinated. One feature which the electronic health insurance
card and the electronic ID card have in common is that these are technically prepared from
the very beginning in such a way that the user can opt to also use these for qualified signatures. The third element of the Federal Government's eCard strategy states that: "All administration procedures that require a qualified signature generally accept the signature
cards that comply with the standards66 agreed to by the Signature Alliance67.
First practical applications show that smartcards are particularly attractive for citizens if
they can use them for both private and public services.
The Federal Network Agency (BNetzA) has already examined and certified products for
qualified electronic signatures68. These products comply with the necessarily high security
classifications. It is not until confirmation has been published on the website of the Federal
Network Agency that a product is confirmed to be product as contemplated by the German
Digital Signature Act (SigG).
65. For information concerning the legal basis for the electronic signature, please refer to http://
www.bsi.bund.de/esig/basics/
66. Refer to http://www.bundesregierung.de
67. Signature Alliance: http://www.signaturbuendnis.de/
68. Federal Network Agency: http://www.bundesnetzagentur.de/enid/Elektronische_Signatur/Produkte_pi.html
page 40
Within the scope of the "D21 Initiative", the field test for the introduction of the electronic
health card will be held in 200669.
4.1.5.2 Data protection
eGovernment offers a host of options and rationalisation potential in the IT sector. Ideally,
data from the most varied contexts is gathered once only by a central function and is 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 eGovernment manual includes a separate module70 with comprehensive information concerning the issue of data-protection-compliant eGovernment.
4.1.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, in particular, depend 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 Law on Equal Opportunities for the Disabled (BGG) came into
effect in order to overcome disadvantages for disabled people, ensure the discriminationfree participation of the disabled in social life, and to enable these people 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 Law on Equal Opportunities for the Disabled (Barrier-free
Information Technology Ordinance – BITV) which came into effect on 24 July 2002.
This ordinance specifies the Web Content Accessibility Guideline 1.0 (WCAG 1.0) from 1999
as the technical standard.
The Barrier-free Information Technology Ordinance, which has been in effect since 1 January 2006, is binding upon public agencies of the federal administration71 and applies to:
a. Internet presence and offers
b. Intranet presence and offers which are available to the general public
c. IT-based graphic user interfaces which are available to the general public
69. Initi@tive 21 e.V.: Project: "Promoting acceptance of the electronic health insurance card" at http://
www.initiatived21.de/leuchttuerme/leuchtturmprojekte/pages/
70. Refer to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter II, module "Dataprotection-compliant eGovernment"
71. Refer also to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter IV, module
"Barrier-free eGovernment"
page 41
4.2
eGovernment applications
4.2.1 Interaction in eGovernment
4.2.1.1
Interaction levels
E-government services can be generally broken down according to interaction levels, i.e.
information, communication and transaction72.
Information primarily covers the provision of information to people, businesses and other
elements of society. Users on this level merely act as recipients of information. This area is
the most developed one, and almost all public institutions are on the Internet with an
extensive web presence.
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 of German administrations
can be described as well advanced.
Transaction applications represent the highest interaction level. This sector covers the real
rendering of services by public administrations. These applications include, for instance,
the electronic receipt and processing of applications or orders as well as the provision of
forms which can be filled in on the computer and directly sent to the correct recipient. Electronic payment or tendering systems also belong to this category.
Up to now, only a few transaction services have already been implemented in full. 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 sparse dissemination of the electronic signature in all parts of society.
Pioneering work is still necessary with regard to the handling of transactions. The following
discussion will hence focus on transaction services and the related organizational and technical challenges.
4.2.1.2
Interaction relations
Besides classification in terms of interaction levels, the different partners involved in eGovernment can also be broken down73.
a. Government to citizen (G2C)
This situation refers to electronic interaction between citizens and administrations. This
area also includes non-profit organizations.
72. Refer to [v. Lucke et al. 2000] page 3
73. Refer to [v. Lucke et al. 2000] page 3
page 42
b. Government to business (G2B)
This term covers electronic relations between administrations and business.
c. Government to government (G2G)
This area covers the vast field of electronic relations between different public agencies
and institutions of the public administration sector.
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.2.2 Transactions in eGovernment
As already mentioned, public administration services not only cover the field of services,
but also include rights and obligations. A functional classification of administrations is
necessary as a precondition for standardising the different types of administrative activity –
and hence the possible transactions. Generally valid types of transactional services can be
identified on this basis.
4.2.2.1
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
Federal states
Municipalities
Public agency
§
Federal Government
Public
agency
Public
agency
G2G
§
Public
agency
Public
agency
§
G2G
G2G
G2G
Public
agency
Public
agency
Public
Publicagency
agency
§
§
G2G
G2C
G2B
€
Citizens
Business
Figure 4-1: eGovernment interaction at a glance
page 43
service-type and intervention-type services on the basis of the different categories of functional administrative branches.
Services mean that citizens or business demand from the administration a service or benefit, i.e. citizens or business initiate the process. Services include:
a. Applications for public funds
b. Granting of subsidies
c. Subsidy and promotion measures
d. Approval procedures
Intervention is a case where the administration intervenes in 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
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.
4.2.2.2
Sub-steps, actions and roles of transaction services
The individual transaction types can be broken down further into individual sub-steps. Substeps consist of one or more actions in which different actors are involved. Examples of substeps, actions and roles related to the service area are discussed in the following. This
methodological approach can then be used as a basis for developing similar models for any
other transaction type.
As a precondition for applying for a service, citizens must first be given the opportunity to
obtain detailed information. The information step is followed by the submission of the
application. The application is passed on to the public agency and from there to the officer
in charge. Other organizational units or public agencies may have to be asked for comments or information. As already mentioned, processes may have to be optimised or reformed in this field. The examination of the case is followed by a decision. This decision may
again have to be sent to other departments or officers for information.
Finally the decision is communicated to the applicant. If the decision corresponds to the
applicant's request, the case is closed and funds are disbursed, if applicable. In this case,
permanent control of the application of funds must be possible. The procedure ends with
archiving as the last sub-step.
page 44
If the applicant does not agree with the decision, remedies in law are available in the form
of a protest or legal proceedings, for example.
This means that the services area can be broken down into sub-steps which are shown in
relation to each other and explained in more detail in Figure 4-2 on page 45 and in
Table 4-1.
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. 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. The officer who receives the application also
confirms its receipt.
In analogy to this procedure, the other sub-steps include further actions and roles which
are summarised in the table below.
Information
Application
Transmission
and receipt
Processing
Comment
and opinion
Decision
Collection of
administrative
fees
Payment or
disbursement
of funds
Control of fund
application
Archiving
Other
procedures
(e.g. appeal)
Transmission
and receipt
Figure 4-2: Sub-steps of transaction services
page 45
Sub-steps
Actions
Roles
Information
Providing information
Requesting information
Interested citizen
Editor
Application
Submission of application
Transmission of application
Receipt of application
Applicant
Post office
Officer
Processing
Examination of the case
Request for information
Officer
Superior
Applicant
Post office
Further officers
Comment and opinion
Information evaluation
Officer
Superior
Further officers
Decision
Writing the decision
Service of the decision
Officer
Superior
Applicant
Post office
Collection of administrative fees
Collection of fees
Payor
Cashier's office
Payment or disbursement of funds
Payment
Payee
Cashier's office
Control of fund
application
Examination of the case
Request for information
Officer
Superior
Payee
Post office
Further officers
Archiving
Archiving
Officer
Records management unit
Reference to other
procedures
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 section 4.2.2.1 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.2.3 Modules for eGovernment applications
The analysis of service types explained above and the related identification of sub-steps,
actions and rules can be used as a basis for identifying functional modules which – given
page 46
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 architecture74.
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
enable functions for access to the eGovernment application. This includes a uniform,
easily recognised 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 standardised, 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 standardise 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 BundOnline2005 Initiative and are described in more detail in
Appendix A on page 119 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 55.
74. Refer to chapter 6 "Computational viewpoint: Reference software architecture" on page 55
page 47
page 48
5 Information viewpoint: Data modelling and standardisation
5.1
Background
One important SAGA goal is to secure the interoperability of eGovernment applications,
refer to section 1.3 "Aims" on page 12. Defining XML as the standard for exchanging data,
refer to section 8.2.3 "Interchange formats for data", merely provides a technical basis for
this. Although XML does offer the necessary foundation, 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 comprehensive interoperability between applications. In order 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 co-ordinated with a view to legal frames of reference (e.g. legislation and regulations). In SAGA, organizational interoperability is
addressed in chapter 4 "Enterprise viewpoint: Fundamentals of eGovernment" on page 35.
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 (for instance SOAP, HTTP, FTP, IP, SMTP). The respective standards are referenced
in the technology viewpoint, for instance in section 8.6 "Communication" on page 94. A
common language for data description is the required technical precondition for interoperability. In section 8.2.3 "Interchange formats for data" on page 75, XML is identified as the
mandatory standard for exchanging data.
Semantic interoperability
Semantic interoperability exists 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 to the content of the data
transmitted.
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 XML schemas (XSD) or by using Regular Language Description for XML New Generation (Relax NG)75.
Moreover, the documentation of the schemas must ensure that the metadata is interpreted
in a uniform manner. For instance, it must be documented whether an element, e.g.
75. Refer to section 8.2.2 "Interchange formats for data models" on page 74
page 49
"Street", also features 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 can then often only take place after other definitions have been made via the schemas. For instance, in order to make it possible to compare
details on 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 Federal Insurance Institute for Salaried Employees (BfA) 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.
5.2
Information on data modelling
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.
The KBSt unit hopes to support data model developers with a host of measures which will
be described in the following section, refer also to Figure 5-1.
Guideline for developers of process and data models
One of the first measures offered by the KBSt is a guideline for developers of process and
data models which is available on the KBSt website76 . This guideline provides those in
Modeler
Recommendations for action
Assistance
Feedback
Guides
Adding own
data models
Reuse of
data models
Publishing project
information
Identification of
related projects
XML Infopoint
Figure 5-1: Support for data model developers
page 50
XML Repository
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 and data modelling complex. The
guideline features information on how to prepare modelling, on modelling itself and on
analysing and optimising existing models. All these topics are addressed in the guideline
and illustrated by examples.
The guideline is continuously updated in order to be able to address the latest developments. This means that user feedback is used to continuously improve the guideline.
XML Infopoint
The KBSt unit also provides another tool on its homepage, i.e. the XML Infopoint77. This is
where information on planned, current and completed projects with an XML reference is
gathered. The following information concerning the individual projects is offered:
a. Short description of the project
b. Topics
c. Focus of application
d. Project partners involved
e. Implementation status
f.
Contact information
This means that those in charge of new projects can use the XML Infopoint in order to gain
an overview of projects already completed or underway on a certain topic. Synergies can
be achieved and work reduced by making use of information publicly available and specifications of projects with a similar topic, or by contacting those in charge of other projects.
Project managers conducting projects with an XML reference for the federal administration
can have their projects recorded in the XML Infopoint.
XML Repository
The XML Infopoint is to be replaced by the KBSt's future XML Repository. The XML Repository will serve as a central point providing data models for reuse. Thanks to quick web
access, creators of data models will be in a position to quickly evaluate whether solutions
from other projects exist to solve a certain problem. Reusing existing models which can be
easily obtained from the XML Repository reduces modelling work. Furthermore, it is easier
to establish interoperability between two projects if both are based on the same models
from the XML Repository.
The XML Repository will not only provide data models in the form of UML diagrams but also
their concrete implementation in the form of XML schemas. An additional functionality will
enable automatic generation of XML schemas from UML data models. The XML Repository
will also store comprehensive documentation of the data models provided which will make
76. Refer to http://www.kbst.bund.de/modellierungsleitfaden
77. Refer to http://www.kbst.bund.de/xml-technologie
page 51
their reuse easier. Furthermore, transformations will be provided as needed. These can be
used to map existing data formats to standardised data formats.
Apart from using data models from the XML Repository, developers are to be encouraged
to also make data models from their own projects available in the XML Repository. In this
way, these data models are not only available to other interested users, but developers can
also directly influence the standardisation of data models, refer to section 5.3 on page 52.
Developer support for data models is an important yet rather passive approach towards
securing semantic interoperability. A more active role is adopted by the public administration when it actively develops standardised data models.
5.3
Standardisation of data models
As already shown in section 5.1, the definition of XML as the standard for data description
in SAGA, refer to section 8.2.3 "Interchange formats for data" on page 75, 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 achieve the standardisation
of data models. The components of data models especially, for instance, address and name,
which occur in many different applications, are presented in a large number of ways. There
is no semantic interoperability since the data model in each application can be described in
a different manner in XML. Standardising these data models can help to reduce the number
of variants and improve the interoperability of applications based on the same standardised data models. There are already some first successful approaches for standardising
data models. These efforts are to be intensified in future.
Private sector standardisation projects have shown that any attempt to achieve a full-scale
standardisation of data models is usually doomed to fail. This is why the German administration's standardisation projects focus on two specific areas. The first area is the standardisation of specific data models and the second area is the standardisation of general data
models, so-called core components.
5.3.1 Definition of specific and general data models
Specific data models are understood to be data models which have a strong reference and
which are usually reused in one area of application only.
Contrary to specific data models, general data models are data models that are used in
many different areas of application. Examples of such data models include name, address
or date of birth.
5.3.2 Standardisation of specific data models
The standardisation of specific data models is, among other things, the task of the prioritary
Deutschland-Online project on "Standardisation"78. In a series of projects, standard models
are being developed here for various topics, for instance XMeld, a data model for the citizens' register. Other projects include XBau, XPersonenstand, XKfz etc. Apart from develo78. Refer to http://www.deutschland-online.de/
page 52
Technical standards
and core components
Standardise
Catalogue of
quality-assured data models
Validate
Compilation of data models
Publish
Figure 5-2: Standardisation process for data models
ping comprehensive data models, these projects also address the legal frames of reference
and, when applicable, changes are proposed.
On completion of the XML Repository, the standardised, specific data models of XML projects – the specific standards – will be available from the XML Repository.
5.3.3 Standardisation of general data models
The standardisation of general data models for the federal administration is being promoted by the KBSt unit in co-operation with the XÖV workgroup and other partners from the
public administration. In future, the results of these standardisation activities, i.e. the core
components, are to be made available via the XML Repository. The use of core components
in the federal administration's IT projects and also in the entire public administration would
make it easier to achieve semantic interoperability for the different applications. At the
same time, it would be possible to reduce modelling work by reusing the existing core
components.
Standardisation process for general data models
In order for standardisation activities to meet the demands and needs of users, a standardisation process for general data models will be established which is to be explained in the
following section. Figure 5-2 on page 53 illustrates the three levels into which the standardisation process can be categorised. These levels, i.e. "Collection", "Catalogue" and "Standards" will also be supported by the XML Repository.
a. Collection:
The first step involves collecting data models that already exist. Information from the
XML Infopoint serves as the starting point for this. The data models of the projects
stored there form a first basis for the further development of the XML Repository. All
data model developers will be encouraged to feed their data models into the collection
of the XML Repository. In addition to this, by feeding their projects into the XML
page 53
Repository, developers can show which data models or also which components of data
models are important for their projects and the requirements which the respective
models must fulfil. This information can be used to derive the need for standardisation
and the requirements for the core components to be developed. The data models
stored in the collection should be used for developing eGovernment applications if no
catalogued or standardised models exist for the respective application area (e.g.
address).
b. Catalogue:
The data models collected are regularly viewed and checked to ensure that they meet
with the defined quality criteria. Data models that meet with the quality requirements,
i.e. are, for instance, sufficiently documented, are compiled in a catalogue of qualityassured data models. The data models which are contained in the catalogue of the XML
Repository should then be used if no standard exists for the respective application area.
c. Standards:
The last step involves determining where the need for a standardised data model – a
core component – exists. This will always be the case where several suitable data
models are recorded for a given application area in the catalogue of the XML
Repository. Depending on the relevant requirements, either one of the data models
contained up to then in the catalogue will be determined as the standard, or a
completely new core component will be created that fulfils as many of the user
requirements as possible for its topic. These standards should be given priority for data
modelling in the Federal Government's eGovernment applications.
The standardised data models will be distributed as core components via the XML Repository and recommended by SAGA for reuse. If necessary, transformations can be provided
which enable conversion of existing models into the new standard format.
Since it can happen that individual core components may not fulfil all possible requirements, it may be necessary to carry out expansions for individual projects. This should,
however, be the exception because such an adjustment always has an adverse effect on
semantic interoperability. Generally speaking, the core components should be as complete
as possible, so that developers can use the entire component or parts of the component
without any expansions.
The standardisation of core components is not only being promoted in Germany but also in
many other countries and on an international level, and repositories are being created to
distribute these core components. On an international level, the United Nations Centre for
Trade Facilitation and Electronic Business (UN/CEFACT) is the leading developer of core
components. As soon as German core components come into contact with international
data traffic, an exchange with international standardisation projects will be sought at an
early point in time.
On the whole, all the measures presented mark a major step forward in the effort to achieve
semantic interoperability. Since it can be expected that the networking of eGovernment
applications, in particular through the introduction of a service-orientated architecture, will
increase, it will be necessary to further intensify in the years to come efforts to achieve
semantic interoperability.
page 54
6 Computational viewpoint: Reference software architecture
The computational viewpoint according to RM-ODP79 describes the architectural structure
of distributed eGovernment applications in abstract form and omits implementation
details. In this chapter, issues of architecture are decided, 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: services80 and systems81) 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 independently of use in eGovernment.
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 SAGA82 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 in the German original version of
SAGA. The arrangement has been kept for the English version in order to ensure consistency of cross-references across both language versions. It does not reflect any weighting of
the individual requirements with a view to software and technical aspects. However, the
aims of interoperability and reusability laid down in SAGA have an outstanding role to play.
79. Refer to chapter 3 „Architecture model for eGovernment applications“, section 3.4 "Computational viewpoint" on page 33
80. Services are entities which provide functionalities for applications. The use of services also make it possible for
external applications to manage the resources provided by the service. Services are specified via their interfaces and the functionality made available.
81. Systems are entities which provide the user with complex functionalities. They may use the services made
available.
82. Refer to section 1.3 "Aims" on page 12
page 55
a. Extensibility
Extensibility refers to the economically reasonable ability to add new functionalities to
the components of an application, or to extend existing functionalities without any
adverse effects on these functionalities.
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 enables quick modification of a distributed architecture in order to improve
availability and reliability or to handle a higher load (scalability).
c. Interoperability
Interoperability refers to the media-consistent implementation of transaction services
between inter-agency applications. One precondition for this is that the administration
processes must be co-orientated so that the eGovernment applications implemented
can interact with each other.
d. Openness
Applications are open when they feature well-defined and documented interfaces or
are encapsulated in such a manner that they can be integrated via portals.
e. Performance
The performance of an application is defined by how quickly it can make its functionality available. A measure for performance is 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 stated security policy.
Confidentiality, integrity and compliance with the Federal Data Act and the relevant
chapters on security in the eGovernment manual must be ensured in the use of online
services, refer also to chapter 9 "Technology viewpoint (part II): data security standards"
on page 105.
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.
i.
Updating capability
eGovernment applications suitable for updating must be operated and updated economically. Efficient updating must be possible for technicians who were not involved in
the development of the application without requiring extensive familiarisation or training.
page 56
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 can take place on several
different levels of abstraction, e.g. exchange of experience between agencies and the
use of joint data and process models, architecture samples 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 probably more important, whilst security issues are likely to be a higher priority in conjunction with complex approval and licensing procedures.
6.2
Implementation options and architecture paradigms
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. Component users can adjust their behaviour in the manner foreseen by the
component creator without accessing the source code.
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
Figure 6-1 on page 58. Since the description of the functionalities offered and consumed by
a component is independent of the actual implementation, the implementations may be
exchanged without the user realising this and this offers many possibilities for the further
development of the implementation.
Another major improvement compared to purely object-orientated concepts is offered by
standardised runtime environments for components in the form of application servers or
light-weight frameworks which offer the declarative use of special, independent services,
such as authorisation, localisation, 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-oriented 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. Figure 6-2
on page 59 provides a visual example of service rendering and service use in a Service Ori-
page 57
Component platform
Component 1
Component 2
Export interface
Export interface
Body
Body
Import interface
Import interface
Figure 6-1: Component-based development
ented Architecture (SOA). The individual levels in the illustration are merely used to show
the logic breakdown and do not represent any layers in the sense of a layer model.
Services make their functionalities available via interfaces (dark circles with bright border in
the middle of Figure 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 can be encapsulated and made available as a
service.
Users (bright circles with dark border in the upper section of the Figure 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 either requires manual access (light circle) or
can be implemented by the use of services (dark circle). Their implementation can be carried out on a stand-alone service or a composition, i.e. a combination of services (symbolised by the border around two service interfaces). The composition of existing services
offers a higher value service for the business processes and users.
The 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 Figure 6-2 in the direction of service interfaces and their compositions), a communication basis must be defined which is based on generally accepted standards83. The service must master these
standards, so that it can be used.
83. Refer to section 8.6.1.2 "Client-to-server communication" on page 96
page 58
Service use
User
Business processes
composed of activities
Service interfaces
Provision of Service
non-divisible and composed
Components
for implementing services
Component
Service 1
Component
Service 2
Component
OFA service
Legacy
system
ERP
system
Operative infrastructure
and data storage
DBMS
Figure 6-2: SOA reference model
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.
6.2.3 Multi-layer architecture
The following section encourages and explains why multi-layer architectures help fulfil the
requirements contained in section 6.1.
Separation of business and data storage logic
The separation of business and data storage logic leads to systems or services which are
independent of database type84 and database manufacturer. In response to growing
requirements, e.g. concerning performance or availability, the database can be exchanged
without having to change the business logic.
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 –
84. In the sense of relational database vs. object-orientated database
page 59
where one server is responsible for the presentation layer 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 lessthan-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.4.1 "Web-based / computerbased access to information" on page 80. Since barrier-freedom and security require that
eGovernment applications remain usable even if all active contents have been deactivated
at the client, the data must be processed at the server end in a separate presentation layer.
Different presentations can be generated for different clients on the basis of the respective
requirements.
Multi-layer architecture
The separation of client, presentation logic, business logic and data storage logic leads to a
multi-layer architecture:
Security
Presentation
Middle layer
Integration components
Communication
Client
Persistence / backend
Figure 6-3: Structural view - multi-layer architecture
a. The client layer is where users and software interact. The data processed by the presentation logic as well as the user interface are visualised. The client layer 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)
page 60
b. The presentation layer implements the processing of application data for the client
(e.g. as a web site) and the interaction between the user and the application. The presentation layer includes all the standards for communication with the relevant terminal
devices of the client layer.
c. The middle layer, also referred to as the business layer, implements the business logic
irrespective of its presentation and processes the data from the persistence layer. 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 layer 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, specific databases as well as existing, non-SAGA-conforming applications, legacy
or ERP systems.
6.3
Reference software architecture for eGovernment applications
Interoperability, reusability, economic efficiency, openness and scalability are the key
requirements for eGovernment applications85. The reference software architecture
described is based on implementation options and architecture paradigms discussed in
section 6.2 which, in turn, are used to fulfil the general requirements contained in
section 6.1. This architecture is based on multi-layer architectures and permits both the use
of services as well as the direct use of components. Implementation should be object-oriented. 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-oriented approach86 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 co-operation
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 within the scope of a service oriented architecture (e.g. response times).
85. Refer to section 1.3 "Aims" on page 12
86. Refer to section 6.2.2 "Service-oriented software architecture" on page 57
page 61
b. The business processes to be supported are so complex that single activities can no longer be implemented on stateless services.
c. The flexibility of the service oriented architecture is not required.
6.3.1 Three-layer architecture for services
Client
When implementing a service with a multi-layer architecture according to section 6.2.3, the
presentation layer is omitted, refer to Figure 6-4 on page 62. The reason for this is that the
services perform their functionality from within the business logic, i.e. the middle layer. The
user of the service is another application (client) which may itself be responsible for presenting the results. Services are performed and used in the manner described in Figure 6-2
on page 59.
Service
user
Middle layer
Communication protocol
Service
platform
Service
component
Component
platform
Persistence /
backend
Service
interface
DBMS
Legacy
system
ERP system
Figure 6-4: Model of a three-layer architecture of services
6.3.2 Four-layer architecture for eGovernment systems
Figure 6-5 on page 63 provides an example layout with a concrete structure for a multilayer architecture of an eGovernment system based on the general description in
section 6.2.3. It can be seen that the presentation layer consists of a Presentation Application Server which generates, for instance, HTML and XML data with Java Server Pages. The
Business Application Server in the middle layer forms the backbone of the application and
page 62
Client
Middle layer
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
performs the special functionalities on the basis of services and components. Via application interfaces (or also service interfaces as shown in Figure 6-4), external applications and
services can access the eGovernment system whilst bypassing the presentation layer.
Legacy and ERP systems are integrated via the respective integration components. The systems provide their functionalities via application interfaces or service interfaces. If necessary, connectors may be needed in order to encapsulate legacy systems.
6.3.3 Security
In order to implement the requirements for security, the design recommendations contained in the eGovernment manual must be considered. The "Secure Integration of eGovernment Applications – SIGA" and "Secure architectures for client-server architectures for
eGovernment" modules in the sub-chapter on "IT and IT security" are particularly relevant.
Although designed for component-based implementation, the architecture principles contained here can usually be applied on a one-to-one basis for service oriented architectures.
page 63
6.3.4 Reuse and integration of OFA offers
When designing an eGovernment application to be created, an examination is conducted
in order to determine which services and systems have to be newly developed and where
existing services and systems can be used. Special consideration must be given, in particular, to the OFA services and OFA systems contained in Appendix A "One-for-all offers" on
page 119 and following87.
If the OFA-system "Data security" is used, refer to section A.4 "OFA system - Data security
("virtual post office")" on page 133, a dedicated client application (the OSCI client enabler)
must be installed at 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 layer
Middle layer
External
application
Application
interface
Service
interface
Persistence /
backend
OFA system
Persistence / backend
Middle layer
Service
interface
ERP system
Persistence /
backend
Application
OFA service
Legacy
system
Infrastructure
ERPsystem
Figure 6-6: Integration of OFA offers
87. Additional OFA offers are listed on the KBSt homepage, refer to http://www.kbst.bund.de/saga-efa.
page 64
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 Figure 6-6 –
are directly located in the middle layer. They offer communication possibilities with applications, such as SAP solutions, in as far as these applications are not available as a service
and can be triggered via a service interface. In the latter case, no special integration components are required.
page 65
page 66
7 Engineering viewpoint: Reference infrastructure
A stable and secure IT infrastructure is the basic precondition for the reliable operation of
eGovernment applications. Today's data protection, data security, efficiency and availability requirements for eGovernment are setting high standards for operators of applications
and infrastructures.
The reference infrastructure for eGovernment applications is modelled on the basis of the
engineering viewpoint according to RM-ODP88 and describes the encapsulation of system
units and their connections. Although the standards and technologies of the reference
infrastructure described do not form part of an engineering viewpoint in the stricter sense,
they were nevertheless included in order to make the presentation as realistic as possible.
The following explanations can be broken down according to the top-down approach to
an engineering viewpoint of a single application.
The recommendations by the German Federal Office for Information Security (BSI) on the
security of eGovernment applications89 and on IT Baseline Protection (former IT Baseline
Protection Manual)90 deserve special consideration in this context. If a lower protection
demand is identified for certain applications, less demanding security requirements can be
applied to a given infrastructure than those considered in the following reference.
Not every public agency requires its own, complete eGovernment infrastructure. Smaller
institutions may well use computer centres of external IT service providers or higher-level
public agencies.
7.1
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 architecture. The following goals are to be achieved by defining parameters for a
reference infrastructure in the sense of an operating environment.
a. Optimum physical protection of systems
b. Optimum availability of systems
c. Optimum security of systems and system components through classification on the
basis of their protection demand
d. Classification of systems and system components according to separate security zones
e. Scalability of systems and infrastructures
f.
Simple service, efficient maintenance and updating of complex eGovernment applications and system components by operating personnel
Figure 7-1 shows a general overall view of a distributed eGovernment application with the
user, network and infrastructure areas.
88. Refer to chapter 3 "Architecture model for eGovernment applications", section 3.5 "Engineering viewpoint"
on page 34
89. Refer to the eGovernment manual at: http://www.bsi.bund.de/fachthem/egov/3.htm
90. Refer to IT baseline protection catalogues at: http://www.it-grundschutz.de/
page 67
U s e r s / e x te r n a l s e r v ic e s
E x te rn a l
a p p lic a t Eio xnt e r n a l
a p p lic a t io n
U ser
U ser
C e n tra l
O F AC e n t r a l
o ffe r O F A
o ffe r
N e tw o rk
In te rn e t
E x tra n e t,
VPN
IV B V
N e tw o rk
access
M anagem ent zone
A ccess
check
A ccess
check
I n f o r m a t io n & s e r v ic e z o n e
A ccess
check
A ccess
check
A ccess
check
L o g ic & p r o c e s s in g z o n e
A ccess
check
D a ta b a c k u p
In fr a s tr u c tu r e
D a ta z o n e
E x te r n a l b a c k u p
Figure 7-1: Engineering viewpoint of an eGovernment application
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 architecture and system structure in order to meet the operational requirements for
eGovernment applications.
page 68
The requirements for a computer centre and its IT infrastructure are described below.
7.1.1 Physical infrastructure
Suitable space is required in order to protect systems against external influences, the elements and unauthorised access. Computer centre operators planning to host eGovernment applications should hence determine the protection demand pursuant to BSI standard 100-2: IT baseline protection approach91 and implement the necessary IT security
measures according to the BSI's IT baseline protection catalogues. This includes, 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.1.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, the four zones described below should at least
be implemented within a computer centre's infrastructure. Operation of complex eGovernment applications may require additional zones. The zones should be strictly physically
separated. This means:
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
page 69
networks. Further information zones should be set up if systems with different security levels are to be operated.
Communication between systems of the information and services zone on the one hand
and systems of the logic and processing zone on the other 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. Furthermore, no zones other than the management zone may be actively accessed
from within this zone.
Management zone
The management zone contains all the systems which are needed for administrative purposes or for monitoring systems in the 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.
Data backup
Every zone should include its own data backup components. Data of the information zones
should also be backed up via protected communication channels.
7.1.3 Network access and access control
Access control systems 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 in TCP/IP-based networks on the
basis of the Network Address Translation (NAT) protocol, and are hence not published in
external networks.
page 70
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 protocol-conforming re-generation of requests.
The communication relations between the internal zones are also subject to access control
systems. 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 zones is not
recommended for security reasons.
7.2
Network, users and external services
The network level is the link between the systems of the computer centre infrastructure
and external services as well as users of eGovernment applications. This level also contains
the Internet, TESTA (Trans-European Services for Telematics between Administrations), the
Federal Administration Information Network (IVBV), the Berlin-Bonn Information Network
(IVBB) 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 make 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 designing eGovernment applications, the necessary bandwidths must be
page 71
made available on the basis of an assessment of the anticipated network communication,
and the access control mechanisms described in section 7.1.3 on page 70 must be implemented.
The federal administration's one-for-all offers (OFA offers) – broken down into OFA services,
OFA systems and infrastructures – will be made available both on the Internet and via the
IVBV network. Additional information about OFA services, OFA systems and infrastructures,
such as the IVBV, can be found in Appendix A "One-for-all offers" on page 119.
Other services, such as the e-payment OFA service, can be accessed via web service interfaces on the Internet. For this purpose, the OFA service provides the web service interfaces
necessary on the server end on the one hand as well as a reference implementation for calling the web services by the relevant eGovernment application on the other. Communication with external applications of other public agencies or enterprises proceed in a similar
manner; middleware communication interfaces may be used for these purposes too.
De-centralised OFA offers, in contrast, such as the OFA systems data security and form
server, are implemented within the computer centre infrastructure of the individual public
agencies. The rules already described in section 7.1 should be observed in this case too.
page 72
8 Technology viewpoint (part I): Standards for the IT architecture
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.
8.1
Process modelling
8.1.1 Modelling methods
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 oriented towards DIN
66001: "Informationsverarbeitung, Sinnbilder und ihre Anwendung" [Information processing, symbols and their use].
Mandatory:
Unified Modeling Language (UML) v2.0
The Unified Modeling Language (UML)92 should be used for object-oriented 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.1.2 Interchange formats for process models
Recommended: XML Metadata Interchange (XMI) v2.x
XML Metadata Interchange (XMI)93 is a standard of the Object Management Group (OMG),
which should be used for the notation and interchange of Meta Object Facility (MOF)based models (e.g. UML) in XML. This format is open and manufacturer-independent.
UML 2.094 can be transformed to XMI 2.0 and XMI 2.1.
92. Refer to http://www.uml.org/
93. Refer to http://www.omg.org/technology/documents/formal/xmi.htm
94. Refer to section 8.1.1 "Modelling methods"
page 73
8.2
Data modelling
8.2.1 Modelling methods
Mandatory:
Entity Relationship Diagram
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) v2.0
UML should be used in data modelling for object-oriented applications. For instance, class
diagrams are the approach of choice which can also be used in other applications or by
other tools. XML data structures can be directly generated from the corresponding specifications.
8.2.2 Interchange formats for data models
Mandatory:
XML Schema Definition (XSD) v1.0
XML schemas should be used for the structured description of data. XML schemas should
comply with the XML Schema Definition (XSD) published by the World Wide Web Consortium (W3C)95.
Recommended: Regular Language Description for XML New Generation (Relax NG)
The ISO standard (ISO/IEC 19757-2:2003) Relax NG96 can, just like XML Schema Definition
(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) tools97.
Recommended: XML Metadata Interchange (XMI) v2.x
Analogous to section 8.1.2 "Interchange formats for process models" on page 73.
95. Refer to http://www.w3.org/XML/Schema
96. Refer to http://www.relaxng.org/ and http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37605&ICS1=35&ICS2=240&ICS3=30
97. Refer to http://www.thaiopensource.com/relaxng/trang.html
page 74
8.2.3 Interchange formats for data
Mandatory:
Extensible Markup Language (XML) v1.0
XML v1.098 is a language derived from the Standard Generalized Markup Language (SGML)
which should be used for structured data description. The language enables the extension
and addition of tags. The data described can be prepared for presentation using the Extensible Stylesheet Language (XSL)99.
XML is to 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.
Under Observation:
Election Markup Language (EML) v4.0
The Election Markup Language (EML) can be used especially for exchanging data in the
environment of eVoting processes.
EML v4.0 was adopted in February 2006 as an 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 (Bundestag elections, municipal elections) or private elections (works council elections, secret ballots). EML can be adapted to
all scenarios and also supplies safety functions for data backup.
Under Observation:
XML v1.1100 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.2.4 Data transformation
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 is
carried out via the XSLT101 language defined by W3C as part of XSL (Extensible Stylesheet
Language).
98. Refer to http://www.w3.org/XML/
99. Refer to "Extensible Stylesheet Language (XSL) v1.0" on page 83
100. Refer to http://www.w3.org/TR/xml11/
101. Refer to http://www.w3.org/TR/xslt/
page 75
8.2.5 Description language for metadata of files
Recommended: Resource Description Framework (RDF)
Resource Description Framework (RDF)102 is a language for presenting information on
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 vocabularies, such as Dublin Core, can also be used in RDF. RDF should be used to describe
metadata for web resources.
Recommended: Dublin Core
Dublin Core103, is a widespread standard that is standardised by ISO104 and NISO and
which was developed by the Dublin Core Metadata Initiative (DCMI). This standard should
be used for the metadata description of websites, digital objects and documents.
Each of the 15 elements of Dublin Core corresponds to one property to which certain
values are assigned. They are optional and can be used as often as required to describe an
object. Other sub-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. Many websites are described in this manner and can be found by
search-phrase-based search engines.
8.2.6 Character sets
The standards defined in section 8.5 "Presentation"105 are applicable to the character sets
to be used for the interchange of data. The character set of individual parts of XML schemas
can be further restricted in this context.
8.3
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, so
that the middleware standards can also be used for simpler applications.
102. Refer to http://www.w3.org/TR/rdf-primer/
103. Refer to http://dublincore.org/
104. Refer to ISO 15836:2003
105. Refer to section 8.5.1.4 "Character sets" on page 83
page 76
The specifications and recommendations are based on the design principles that were defined within the scope of the BundOnline2005 initiative, i.e. operating-system neutrality,
interoperability and portability.
Middleware services - such as replication, distributed transaction management, personalisation, internationalisation, messaging, etc. - are referenced in the current version to a certain extent.
Deviations from preferred technologies (i.e. mandatory and recommended technologies)
are acceptable in justified cases, for example, in the case of significant economic advantages.
8.3.1 Application architecture with middleware
Mandatory:
Java 2 Platform, Enterprise Edition (J2EE) v1.4
The development and integration of the following applications (integrated applications) on
the middle layer, i.e.
a. One-for-all offers (OFA offers)
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)
require the use of Java 2 Platform, Enterprise Edition (J2EE)106 technologies.
J2EE is a specification which defines several programming interfaces and a development
process. J2EE in its entirety constitutes an architecture that considers and supports major
aspects of business-critical applications. J2EE already offers important function modules
which can be used to develop applications. Versions 1.4 and higher even include, as socalled core libraries, standard application programming interfaces (APIs) and technologies
which were still classified individually in SAGA 1.1, i.e. 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.
Compared to J2SE, J2EE offers as so-called optional libraries several APIs and technologies,
including for instance, Java Message Service (JMS) 1.1, J2EE Connector Architecture (JCA)
1.5, Java Transaction API (JTA) 1.0, JavaMail API 1.3, Java API for XML Registries (JAXR) 1.0,
Java Management Extensions (JMX) 1.2, Enterprise JavaBeans (EJB) 2.1107, Web Services 1.1,
Java Server Pages (JSP) 2.0 and Servlet API 2.4. In the following, the use of the JMS and J2EE
Connector Architecture communication technologies will be classified as mandatory. The
Java EJB and Servlet-API middleware technologies form the basis for application server
applications.
106. Refer to http://java.sun.com/javaee/
107. Instead of using EJB, a different Application Framework can be used, such as the Spring Application Framework, refer to http://www.springframework.org/
page 77
Thanks to the Java Community Process108, more and more application-near modules will
increase the diversity of J2EE in the near future. New modules are defined via so-called Java
Specification Requests (JSR).
Mandatory:
Java 2 Platform, Standard Edition (J2SE) v1.4
If an application does not require full J2EE functionality either initially or on a permanent
basis, J2EE technologies should be used individually as an alternative solution. The basis for
this is the Java 2 platform Standard Edition (J2SE)109. The individual technologies should be
used in accordance with J2EE Specification 1.4 in order to create a compatible migration
path to J2EE.
Mandatory:
Java Network Launching Protocol (JNLP) v1.5
Java applications should be delivered via the Internet using the Java Network Launching
Protocol (JNLP)110. In this case, the "Java Web Start"111 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).
Under Observation:
Java Platform, Enterprise Edition (Java EE) v5
The difference between Java EE112 v5, which was finalised in May 2006, and its predecessor
can be found 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.
Under Observation:
Java Platform, Standard Edition (Java SE) v5
The new version 5 of Java SE113 has been finalised and now comes with a host of new features in runtime behaviour as well as a number of new language features.
Under Observation:
Microsoft Windows .NET Framework v2.0
.NET Framework is a middleware technology developed by Microsoft. The system architecture of .NET includes a runtime environment for different programming languages and a
development environment. It supports major web standards (including SOAP, WSDL, UDDI,
XML).
108. Refer to http://www.jcp.org/
109. Refer to http://java.sun.com/javase/
110. Refer to http://java.sun.com/products/javawebstart/download-spec.html
111. Refer to http://java.sun.com/products/javawebstart/
112. Refer to http://java.sun.com/javaee/
113. Refer to http://java.sun.com/javase/
page 78
Core components of .NET Middleware were standardised by international organizations114.
Not all parts of .NET were included in the standardisation process so that it is not ensured
that applications can always be completely ported to different operating systems. Projects
are currently underway which aim to implement core components of .NET middleware on
non-Windows operating systems115.
8.3.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
PHP116 (recursive acronym for "PHP: Hypertext Preprocessor) can be used for applications
without an integration requirement, i.e. non-distributed, stand-alone applications which do
not communicate with one of the one-for-all offers (OFA offers), with legacy systems or
other eGovernment 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-oriented programming concepts. Procedures for data encapsulation, referencing of variables and exception handling mark
important progress within the scope of further development.
8.4
Client
The client is a software on a terminal device which makes use of a service offered by middleware. The client layer includes both the classical user site with all the options state-of-theart 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 by industrial companies)
Standardisation 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 low-profile hardware and software requirements and rely on the server to provide as much functionality as possible.
114. .NET v2.0 is based on ECMA standards 334 and 335
115. Refer to http://www.mono-project.de/
116. Refer to http://www.php.net/
page 79
8.4.1 Web-based / computer-based access to information
Two different clients are generally available on computers in order to access or receive
information, i.e. 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 authorisation – to the operating system. 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 12.
8.4.1.1 Web browsers
In order to enable wide-spread use the of the eGovernment applications on offer, web
browsers should be used as the front-end device which must be capable of processing and
presenting the presentation-layer formats (refer to section 8.5). The following browserbased 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.6.3 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 BITV117.
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.5.1.5 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 integer. 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.118
d. A positive list of supported plug-ins is available and published on the web at: http://
www.kbst.bund.de/saga-plugins.
e. Configuration examples are prepared for usual browser types and made publicly available by BSI on the Internet.
f.
The confidentiality of form data must be ensured during transmission by using TLSencrypted channels and pertinent server certificates.
g. The statutory instrument (ordinance) on barrier-freedom remains fully applicable to the
use of permitted client technologies.
117. 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/)
118. Further information on this subject can be found on the web at: http://www.kbst.bund.de/saga-applets.
page 80
8.4.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 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 and must be updated as
required by technical progress. Updates can be made available on CD-ROM or as signed
applications for downloading119 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, for example, in accordance with the OSCI transport specifications.
No protocols other than those defined in section 8.6.1.2 are permitted for any 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
CD-ROM is also offered.
g. The statutory instrument (ordinance) on barrier-freedom must be taken into consideration.
8.4.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.6.3 "Application protocols". Note
that the communication of these clients is standardised 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.4.2 Access to information by mobile phone / PDA
Mobile phones or PDAs must support the presentation layer standards offered by servers,
refer to section 8.5.2 on page 93
119. Refer also to "Java Network Launching Protocol (JNLP) v1.5" on page 78
page 81
8.4.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 communication120.
8.5
Presentation
The presentation layer 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.5.1 Information processing - computer / web
8.5.1.1
Presentation for the disabled
Mandatory:
Barrier-free information technology ordinance (BITV)
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 "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)"121 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 Guidelines122 of W3C, version 1.0. Concerning the issue of barrier
freedom, refer also to section 4.1.5.3 on page 41.
8.5.1.2
Interchange formats for hypertext
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.01123 supports more multimedia options, script languages and improved forms
120. Refer to sections 8.2 "Data modelling", section 8.3 "Application architecture", 8.6 "Communication", and
8.7 "Connection to the backend"
121. Refer to http://bundesrecht.juris.de/bitv/
122. Refer to http://www.w3.org/TR/WCAG10/
123. Refer to http://www.w3.org/TR/html401/
page 82
and print functions. The use of HTML v4.01 is necessary for the technical implementation of
barrier-free 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 internationalisation
of documents in an effort to make the World Wide Web truly world-wide.
Under Observation:
Extensible Hypertext Markup Language (XHTML) v1.0
XHTML v1.0124 formulates HTML v4.01 as an XML application. XHTML v1.0 is to be used
when new browser generations supporting XHTML are developed and launched.
8.5.1.3 Stylesheets
In order to achieve uniform presentation of the information offered, stylesheets may be
used. Stylesheets are format templates for data of all kinds which describe how markups
must be presented in SGML125-compliant languages.
Recommended: Cascading Style Sheets Language Level 2 (CSS2)
Cascading Style Sheets Language Level 2 (CSS2)126 should be used to design HTML pages.
Recommended: Extensible Stylesheet Language (XSL) v1.0
Extensible Stylesheet Language (XSL)127, version 1.0, should be used to transform and present XML documents, for instance, in HTML files.
8.5.1.4
Character sets
Mandatory:
Unicode v4.x UTF-8
In order to provide a sufficient number of characters for the different characters, numbers
and symbols used world-wide, the character set used for documents in the HTML format
should be ISO 10646:2003 (also known as Unicode v4.x) in UTF-8 encoding128.
Recommended: Unicode v4.x UTF-16
ISO 10646:2003 (also know as Unicode v4.x) should be used in UTF-16 encoding129 for
documents in Greek or other non-European languages.
124. Refer to http://www.w3.org/TR/xhtml1/
125. Standard Generalized Markup Language
126. Refer to http://www.w3.org/TR/REC-CSS2/
127. Refer to http://www.w3.org/TR/xsl/
128. This specification is available at http://www.unicode.org/
129. This specification is available at http://www.unicode.org/
page 83
8.5.1.5 Static and dynamic, passive and active contents
Static contents are files which are generated by a web server outside runtime but which
are typically read from the file system and delivered, refer to sections 8.5.1.8 to 8.5.1.19
Dynamic contents are files which are generated during runtime on the server - for
example, in response to database queries – and then delivered.
Passive contents are files which do not contain any program code or computer programs
or which reload during runtime. Active contents are computer programs 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.4 on page 79 must be taken into consideration.
Mandatory:
ECMA-262 – ECMAScript Language Specification
If Javascript is used within HTML pages in accordance with section 8.4.1.1, it must comply
with the ECMA-262130 specification.
Recommended: Servlets / Java Server Pages (JSP) v2.0 / Extensible Stylesheet Language (XSL) v1.0
JSP131 and XSL132 servlet technologies should be selected for the server-based, dynamic
generation of HTML pages.
Under Observation:
Java Server Pages (JSP) v2.1
The JSP v2.1133 standard can be used for the server-based, dynamic generation of HTML
pages. This technology is not yet as widespread as its predecessor version, JSP v2.0.
8.5.1.6 Web forms
Under Observation:
XForms v1.0
XForms is a specification134 for web forms. The aim of this specification is to replace the
forms formulated 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 a number of plug-ins are available, XForms is, however, not
yet supported by most Web browsers currently used.
130. Refer to http://www.ecma-international.org/
131. Refer to http://java.sun.com/products/jsp/
132. Refer to http://www.w3.org/TR/xsl/
133. Refer to http://java.sun.com/products/jsp/
134. Refer to http://www.w3.org/MarkUp/Forms/
page 84
8.5.1.7
Type identification for file formats
Mandatory:
Multipurpose Internet Mail Extensions (MIME) v1.0
The Multipurpose Internet Mail Extensions (MIME) format must be used for the standardised 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 2049135.
8.5.1.8 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.
Mandatory:
Portable Document Format (PDF) v1.4
Adobe’s platform-independent Portable Document Format (.pdf) is to be used for text
documents where no further editing is foreseen and to support forms and barrier-free text
documents. PDF version 1.4 is used by the Acrobat software136 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 contents137.
Mandatory:
Hypertext Markup Language (HTML)
Hypertext documents used for exchanging information, e.g. newsletters, should be presented in HTML format, refer to section 8.5.1.2.
Recommended: Portable Document Format (PDF) v1.5
PDF version 1.5 is not yet as widespread as 1.4. Moreover, no distribution of the Acrobat
Reader for PDF v1.5 is available for Linux/Unix systems and older versions of Windows and
MacOS. PDF version 1.5 is used by the Acrobat software138 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 contents139.
Under Observation:
PDF v1.6 is currently used to a very limited extent only. It features enhancements in the
areas of cryptography and the embedding of file attachments. PDF version 1.6 is used by
135. Refer to http://www.ietf.org/rfc.html
136. Refer to http://www.adobe.de/products/acrobat/readermain.html
137. Refer to http://www.bsi.bund.de/fachthem/egov/download/4_IntAuf.pdf
page 85
the Acrobat software140 version 7 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 contents141.
8.5.1.9 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 with layout
information.
Mandatory:
Text (.txt)
Simple text documents foreseen for further processing are exchanged in the widely used
plain text (.txt) format in order to ensure general readability. The character sets to be used
are defined in section 8.5.1.4.
Under Observation:
Open Document Format for Office Applications (OpenDocument)
v1.0
OpenDocument142 was standardised 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 should be used for exchanging complex documents
that are foreseen for further processing. OpenDocument v1.0 was adopted by ISO for standardising. In May 2006, it was published as a Draft International Standard (DIS) under the
name ISO/IEC DIS 26300. OpenDocument is, for instance, supported by the platform-independent, license-free, open OpenOffice.org143 package144
8.5.1.10 Formats for spreadsheets for exchanging information
Spreadsheets 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.
Mandatory:
Analogous to section 8.5.1.8 on page 85.
142. Refer to http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-os.pdf
143. Refer to http://de.openoffice.org/
144. Based on the XML file formats used in Microsoft Office 2003, Microsoft developed the "Office Open XML" document format (http://www.microsoft.com/office/xml/) and submitted this to ECMA for standardisation. Microsoft has announced that the next Office generation "Office 2007" is to directly support "Office Open XML".
Free plug-ins are planned for Office 2000/XP/2003. Because the license for "Office Open XML" is not to feature
any hurdles for the use in any particular software, it can be expected that other Office products will quickly
support this. Since standardisation has not yet been completed, "Office Open XML" cannot yet be classified in
SAGA, refer to section 2.3.1 "Classification in SAGA" on page 21. This standard can only be evaluated after
standardisation has been completed.
page 86
Under Observation:
8.5.1.11 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:
Character Separated Value (CSV)
Tables with simply structured data must be exchanged as .csv files.
Under Observation:
v1.0
Refer to section 8.5.1.9 on page 86. OpenDocument supports the referencing of formula
languages, however, these do not form part of the standard. An OASIS Technical Committee is working on a suitable specification145.
8.5.1.12 Formats for presentations for exchanging information
Presentations 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.
Mandatory:
Mandatory:
Hypertext Markup Language (HTML)
Presentations in hypertext document format that should not be changed should be
exchanged in HTML format, refer to section 8.5.1.2 "Interchange formats for hypertext" on
page 82.
145. Refer to http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office-formula
page 87
Under Observation:
Under Observation:
Synchronized Multimedia Integration Language (SMIL) v2.0
SMIL is an XML-based, standardised language for writing interactive multimedia presentations146. "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."147
There is a host of SMIL players, also free of charge. Of the browsers currently available on
the market, up to now only the Internet Explorer supports a subset of SMIL148.
8.5.1.13 Formats for presentations for further processing
It must be possible to edit presentations which are foreseen for further processing.
Under Observation:
v1.0
8.5.1.14 Interchange formats for graphics
Mandatory:
Graphics Interchange Format (GIF)
In view of its widespread use, the Graphics Interchange Format (.gif) should be used for
exchanging graphics and diagrams, with (.gif) graphics files being compressed with a
colour depth of 256 colours (8 bits per pixel).
Mandatory:
Joint Photographic Experts Group (JPEG)
The Joint Photographic Experts Group (.jpg) format must be used for exchanging photographs. This format supports changes in the compression factor and the definition of the
density, so that a compromise between file size, quality and use is facilitated. 16.7 million
colours (24-bit colour information) are supported.
Recommended: Portable Network Graphics (PNG)
The Portable Network Graphics149 (.png) format should be used whenever this is possible.
The (.png) is license-free. It supports 16 million colours, transparency, loss-free compres146. Refer to http://www.w3.org/TR/2005/REC-SMIL2-20050107/
147. Refer to Pauen, Peter: Zukunftsorientierte Ansätze – SMIL [Future-orientated approaches – SMIL] http://
www.informatik.fernuni-hagen.de/import/pi3/ peter/smil.htm
148. Refer to http://www.w3.org/AudioVideo/#SMIL
149. Refer to http://www.w3.org/TR/PNG/
page 88
sion, incremental display of graphics (beginning with the gross structure until the file is
completely transmitted) and the identification of damaged files. This format was standardised by ISO (ISO/IEC 15948:2003).
(.png) will become mandatory instead of (.gif) as soon as new browsers which fully support
this format have become established.
Recommended: Tagged Image File Format (TIFF) v6.0
TIFF150 can be used for saving bitmap graphics. TIFF is supported by all conventional graphic and presentation programs. In order to achieve maximum interoperability, the properties of the "Baseline TIFF"151 must be used exclusively. TIFF can be used when the format
must be capable of presenting documents consisting of several pages. TIFF is particularly
suitable for scanned text documents (b/w graphics or graphics with grey shades).
Recommended: Geo Tagged Image File Format (GeoTIFF)
GeoTIFF152 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 2000153 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-data154. Browser support for JPEG 2000 is only available using
plug-ins. Classification of JPEG 2000 is limited to the first part of the ISO standard155
because this contains the core functionality and is the most useful standard.
8.5.1.15 Interchange formats for geo-information
The standards listed below for exchanging geo-information are used in the geo-services in
section 8.6.5 on page 99.
Recommended: Geography Markup Language (GML) v3.1.1
GML156 is a mark-up language used to interchange and save geographical information in
vector format which considers spatial and non-spatial properties. This specification was car150. Refer to http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
151. "Baseline TIFF" compiles the properties of TIFF files which must be supported by 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.
152. Refer to http://www.remotesensing.org/geotiff/
153. Refer to http://www.jpeg.org/jpeg2000/
154. Refer to OGC: "GML in JPEG 2000 Interoperability Experiment (GMLJP2)", http://www.opengeospatial.org/
initiatives/?iid=154
155. ISO/IEC 15444-1:2004
156. Refer to http://www.opengeospatial.org/specs/
page 89
ried out by the Open Geospatial Consortium (OGC)157. 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.0, refer to section 8.6.5 "Geo-services" on page 99.
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.0, refer to section 8.6.5 "Geo-services" on page 99.
8.5.1.16 Interchange formats for audio and video files
Mandatory:
Quicktime (.qt, .mov)
The customary Quicktime format158 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 standardised as ISO/IEC-14496. MP4 is known as part 14 of the MPEG-4
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. MPEG-4 should be used as codec.
Under Observation:
Ogg
Ogg is an open, manufacturer-independent container format for audio and video files. It is
developed by the Xiph.org Foundation159 and is supported by many media players.
With the Ogg container format, different codes can be used depending on the application
in question. Theora160 can be used for video data. Speex161 is suitable for audio files with
low quality requirements, for example, voice recordings. Vorbis162 which features a quality
that is equivalent to MP3 can be used for audio files with normal quality requirements. The
loss-free Audio-Codec FLAC163 can be used for cases where the maximum quality is
required.
157. Refer to http://www.opengeospatial.org/
158. Refer to http://quicktime.apple.com/
159. Refer to http://www.xiph.org/ogg/
160. Refer to http://www.theora.org/
161. Refer to http://www.speex.org/
162. Refer to http://www.vorbis.com/
163. Refer to http://flac.sourceforge.net/
page 90
Under Observation:
Windows Media Video (.wmv) v9
The quality of the Windows Media Video (WMV) format is better than that of the Quicktime
format. However, players for different operating systems are not yet available for the WMV
format to the same extent as in the case of Quicktime. The exclusive use of WMV is only
possible in the case of homogenous target groups whose operating systems are known
and supported by players for WMV v9.
Under Observation:
RealMedia v10 (.rm, .ram)
RealMedia from RealNetworks164 is the container format for the RealAudio audio format
and RealVideo video format. All these formats are proprietary. The quality of RealVideo
exceeds that of the Quicktime format. A free player is available for all conventional platforms as well as some mobile devices. The exclusive use of RealMedia is only possible in the
case of homogenous target groups whose operating systems are known and supported by
players for RealMedia v10.
8.5.1.17 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 characterised 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 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 in any
case enable the transport of streaming data via HTTP.
Mandatory:
Quicktime (.qt, .mov)
In order to achieve the maximum possible degree of compatibility between the streaming
signal and commonly used web browsers, audio and video clients and/or plug-ins, Quicktime format165 should be used; refer to section 8.5.1.16 on page 90.
164. Refer to http://www.realnetworks.com/
165. Refer to http://quicktime.apple.com/
page 91
Recommended: MPEG-4 Part 14 (MP4)
MP4 can be used for streaming video sequences. MPEG-4 should be used as the codec,
refer to section 8.5.1.16 on page 90.
Under Observation:
Ogg
Ogg is an open, manufacturer-independent container format that can be used for streaming audio and video.
Refer to section 8.5.1.16 on page 90 for information concerning suitable audio and video
codecs.
Under Observation:
Windows Media Video (.wmv) v9
In the case of WMV format v9, neither the players nor streaming servers have yet achieved
wide availability for different operating systems.
Under Observation:
RealMedia v10 (.rm, .ram)
When RealMeadia is used for streaming applications, it must also be considered that the
prices for the RealMedia servers, called Helix servers, are high compared to Windows Media
or Quicktime. However, the Helix Universal servers also support Windows Media and Quicktime.
8.5.1.18 Animation
Mandatory:
Animated GIF
Animation means moving features in graphics displayed on a site. Animated GIF, a variant
of the GIF graphic format, should be used in this case. 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.5.1.19 Data compression
Compression systems should be used in order to enable the interchange of large files and
minimise network load.
page 92
Mandatory:
ZIP v2.0
Compressed data should be exchanged as (.zip) files in the internationally used ZIP166 format.
Recommended: GZIP v4.3
An alternative is the GZIP format, version 4.3, with (.gz) files as specified in RFC 1952167.
8.5.2 Information processing - mobile phone / PDA
In the event that an information offer for mobile phones and PDAs is to be developed, preference should be given to the SMS system because this is widely accepted by citizens. The
presentation of websites for mobile communications is not yet widely used in Germany.
Mandatory:
Short Message Services (SMS)
Short Message Services are to be implemented on the basis of the specifications issued by
the SMS Forum168. The SMS Forum is an international forum of all major IT companies.
Under Observation:
Wireless Application Protocol (WAP) v2.0
The Wireless Application Protocol (WAP)169 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
the predecessor version, the presentation possibilities have become much more similar to
those on the Internet.
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.
The majority of mobile terminal 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
XHTML Basic170 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). Subsets of XHTML Basic are currently being defined for different terminal devices.
166. Refer to http://www.pkware.com/business_and_developers/developer/popups/appnote.txt
167. Refer to http://www.ietf.org/rfc/rfc1952.txt
168. Refer to http://www.smsforum.net/
169. Refer to http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html
170. Refer to http://www.w3.org/TR/xhtml-basic/
page 93
Like WML v1.0, WML v2.0 is once again based on XML. It is, however, a subset of the XHTML
Mobile Profile Specification which, for its part, is a subset of XHTML Basic.
8.5.3 Information processing - external systems
Refer to sections 8.2 "Data modelling", 8.3 "Application architecture", 8.6 "Communication"
and 8.7 "Connection to the backend". However, only a subset of the standards mentioned
in the middleware area is relevant for communication with external systems. XML and web
service technology are at the heart of communications with external systems. Existing
interfaces that are based on OSI technology will be gradually migrated.
8.6
Communication
Within the "communication" element, a distinction is made between application, middleware and network protocols as well as directory services.
8.6.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.6.1.1, and client applications outside the administration which communicate with an administration server, refer to
section 8.6.1.2.
8.6.1.1
Server-to-server communication within the administration
Mandatory:
Remote Method Invocation (RMI)
Java RMI171 is particularly suitable for internal communication between Java objects. Via
RMI, an object on a Java Virtual Machine (VM) can invoke methods of an object that runs on
another Java VM. Java Remote Method Invocation is part of the Java 2 Standard Edition
(J2SE) and hence also part of the Enterprise Edition (J2EE).
Mandatory:
Simple Object Access Protocol (SOAP) v1.1
SOAP172 should be used for communication between the party supplying the server and
the user of a server within the meaning of the SOA reference model173. SOAP can be used
to exchange structured data as XML objects between applications or application 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 standardised language174 that describes web services in such a manner
171. Refer to http://java.sun.com/rmi/
172. Refer to http://www.w3.org/TR/soap11/
173. Refer to Figure 6-2 on page 59
page 94
that they can be used by other applications without a need to know further implementation details or to use the same programming language.
Mandatory:
The data elements to be transmitted are to be specified via XML Schema175.
Mandatory:
Java Message Service (JMS) v1.1
JMS176 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 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 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
JCA177 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 J2EE environments. The JCA resource adapter frequently uses messages, such
as JMS, in order to communicate with legacy systems.
Recommended: Remote Method Invocation over Internet Inter-ORB Protocol (RMIIIOP)
Java RMI-IIOP178 is an integral part of the Java 2 Standard Edition (J2SE) and hence also part
of the Enterprise Edition (J2EE). 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 comply with the latest CORBA specification 2.3.1179. The
remote applications are hence not limited to the Java language.
The data elements to be transmitted can be specified using Relax NG. The Relax-NG schemas must, however, be transformed to XML schemas, refer to section 8.2.2.
174. Refer to http://www.w3.org/TR/wsdl
175. Refer to http://www.w3.org/XML/Schema
176. Refer to http://java.sun.com/products/jms/
177. Refer to http://java.sun.com/j2ee/connector/
178. Refer to http://java.sun.com/products/rmi-iiop/
179. Refer to http://omg.org/cgi-bin/doc?formal/99-10-07
page 95
8.6.1.2 Client-to-server communication
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, it enables client systems
to invoke the functions of the applications via the Hypertext Transfer Protocol (HTTP). A
web service is a software component which uses SOAP in order 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.2 "Data modelling" as a universal and primary standard for the interchange of 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.1180 and includes XML Schema v1.0, SOAP v1.1, WSDL v1.1 and UDDI v2.0.
Mandatory:
Simple Object Access Protocol (SOAP) v1.1
Mandatory:
Web Services Description Language (WSDL) v1.1
Mandatory:
Under Observation:
Universal Description, Discovery and Integration (UDDI) v2.0
The UDDI protocol is the basis for designing a standardised, 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 OASIS181. UDDI is based on standards issued
by W3C and the Internet Engineering Task Force (IETF), such as XML, HTTP, DNS and SOAP.
180. Refer to http://www.ws-i.org/Profiles/BasicProfile-1.1.html
181. Refer to http://www.uddi.org/
page 96
8.6.2 Network protocols
Mandatory:
Internet Protocol (IP) v4
The IT environment of the federal administration currently uses IP v4 (RFC 0791, RFC 1700)
in conjunction with TCP (Transmission Control Protocol, RFC 793) and UDP (User Datagram
Protocol, RFC 768).
Under Observation:
Internet Protocol (IP) v6
IP v6 is the next version of the IP protocol which is not yet 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. For further information on
this subject, please refer to the website of the "Sicherheit im Internet" [Security on the Internet] action group182 or of the German Federal Office for Information Security183.
When new system components are to be introduced, these new components should support both IP v4 and IP v6 in order to enable future migration.
Mandatory:
Domain Name Services (DNS)
Domain Name Services (DNS, RFC 1034, RFC 1035, RFC 1591) have been a standard Internet
feature since the mid-1980s. 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.
8.6.3 Application protocols
Section 9.4.2 deals with the integration of security-related infrastructure components (e.g.
directory services for certificates, revocation lists, etc).
Mandatory:
File Transfer Protocol (FTP)
The File Transfer Protocol (FTP, RFC 959, RFC 1123, RFC 2228, RFC 2640) is considered the
standard file transfer protocol. FTP is one of the oldest Internet services. FTP enables the
shared use of files, offers users standardised 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 or passwords before sending, it is not suitable for
applications with a high security requirement. In such cases, secured methods should be
used, refer to section 9.5.1 on page 113.
182. Refer to http://www.sicherheit-im-internet.de/
183. Refer to http://www.bsi.de/
page 97
Mandatory:
Hypertext Transfer Protocol (HTTP) v1.1
HTTP v1.1 (RFC 2616) is to be used for communication between client and web server.
However, web servers should also support HTTP v1.0 (RFC 1945) in addition to version 1.1.
The HTTP State Management Mechanism (RFC 2965) standard is to be adopted in conjunction with HTTP Session Management and cookies.
Mandatory:
Simple Mail Transfer Protocol (SMTP) / Multipurpose Internet Mail Extensions (MIME) v1.0
E-mail protocols that comply with SMTP / MIME184 specifications for exchanging messages
(RFC 821, RFC 822, RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) are required for
e-mail transport. E-mail attachments should correspond to the file formats defined in
section 8.5.
Mandatory:
Post Office Protocol (POP) 3 / Internet Message Access Protocol (IMAP)
In exceptional cases, it may be necessary to offer electronic mailboxes. POP3 or IMAP
should be used as commonly used standards to this effect.
Under Observation:
WWW Distributed Authoring and Versioning (WebDAV)
WebDAV185 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. 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.
8.6.4 Directory services
Mandatory:
Lightweight Directory Access Protocol (LDAP) v3
LDAP v3 (RFC 2251) is an X.500-based Internet protocol which is optimised with regard to
hierarchically structured information and which is used for directory service access.
Under Observation:
Universal Description, Discovery and Integration (UDDI) v2.0
Analogous to section 8.6.1.2 "Client-to-server communication" on page 96.
184. Refer also to section 8.5.1.7 "Type identification for file formats" on page 85
185. Refer to http://www.webdav.org/
page 98
Under Observation:
Directory Services Markup Language (DSML) v2
DSML186 is a definition in XML which enables access to directory services. It enables the
handling of several directories at the same time.
8.6.5 Geo-services
All standards in this section are either specifications of the Open Geospatial Consortium
(OGC)187 or are based on these specifications. The definition of formats for exchanging
geo-information can be found in section 8.5.1.15 on page 89.
Mandatory:
Catalogue Service (CAT) v2.0.1
Catalogue services enable the finding, search and filtering of geo-data stocks. CAT v2.0.1188
contains an abstract specification for catalogue services.
Recommended: Application profile CSW-DE v1.0.1
This is an application profile for implementing a geo-metadata catalogue service on the
basis of Catalogue Service (CAT) v2.0.1. Geo-metadata modelled pursuant to ISO 19115 and
ISO 19119 is exchanged. The profile is used by the Federal Government, the federal states
and central municipal organizations for the interoperable interchange of metadata within
the scope of Geodateninfrastruktur Deutschland (GDI-DE) [Geo-data infrastructure Germany]189.
Mandatory:
Web Map Service (WMS) v1.1.1
WMS190 is a HTTP-based, standardised service which provides interfaces for presenting
geographical information in the form of image files. The maps generated can be visualised
in any conventional web browser. This means that WMS is a simple and for users easy-toimplement possibility for interoperable access (read access) to distributed and heterogeneous geo-data stocks.
WMS v1.1.1 is referenced in the application profile for Web Map Services within Geodateninfrastruktur Deutschland [Geo-data infrastructure Germany] (WMS-DE profile) v0.9.x191.
WMS v1.1.1 itself references the Geography Markup Language (GML); refer to
section 8.5.1.15 "Interchange formats for geo-information" on page 89.
186. Refer to http://www.oasis-open.org/
187. Refer to http://www.opengeospatial.org/
189. Refer to http://geoportal.bkg.bund.de/nn_32724/SharedDocs/Publikationen/DE/Dokumente/
DE__Navigation.html__nnn=true
191. Refer to http://www.gdi-de.de/de/download/WMS_Profil_V09.pdf
page 99
Recommended: Web Map Service (WMS) v1.3.0
Compared to its predecessor version 1.1.1, WMS v1.3.0192 is not yet so widely used.
Recommended: Web Coverage Service (WCS) v1.0.0
WCS193 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.0
WFS v1.0.0194 enables access to geo-data objects (features), usually in the form of vector
data. Data is exchanged in Geography Markup Language (GML) v2.1.2, refer to
section 8.5.1.15 "Interchange formats for geo-information" on page 89.
Recommended: Web Feature Service (WFS) v1.1.0
Compared to its predecessor version 1.0.0, WFS v1.1.0195 is not yet so widely used. Data is
exchanged in Geography Markup Language (GML) v2.1.2, refer to section 8.5.1.15 "Interchange formats for geo-information" on page 89.
Recommended: Simple Feature Access – Part 2: SQL option (SFA-2) v1.1.0
SFA-2196 defines interfaces for accessing geo-data objects (features). Along with OGC, this
standard was standardised by ISO and is hence also called ISO 19125-2.
8.7
Connection to the 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
page 100
b. Integration via a separate integration layer, 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 proved to be suitable with
the three above-mentioned operating modes.
8.7.1 Dialogue systems
The integration of legacy systems of this kind into eGovernment solutions of the German
administration is possible with or without an integration layer.
a. With an integration layer
New user interfaces are developed for presentation in the browser. Processing of the
legacy data will then take place in a separate integration layer.
b. Without an integration layer
A suitable product migrates the existing dialogues to user interfaces which can then be
executed in a browser.
8.7.2 Batch processing
Many large communication systems process their data by batch processes, in particular,
when large amounts of data are to be processed. The data is supplied on data volumes or
transmitted by file transfer.
Recommended: Extensible Markup Language (XML) v1.0
With this mode, data transmission via documents in XML format197 is to be supported in
future, refer to section 8.2.3 "Interchange formats for data" on page 75. This opens up new
options and increases the flexibility of interfaces.
Under Observation:
Analogous to section 8.2.3 on page 75.
8.7.3 Program-to-program communication
Certain interfaces are widely used by federal administrations. These interfaces are to be
applied and modernised.
page 101
Exchanging information using documents in XML format198 has become the established
procedure when it comes to adapting processing interfaces still based on proprietary protocols to modern technologies, refer to section 8.2.3 on page 75. Today, many manufacturers offer the interfaces needed to convert data to XML formats, so that development
requirements are reduced and the development of a separate connector functionality may
no longer be necessary.
Recommended: Web Services
Web services are the medium of choice for data transmission199. Chapter 6 presents the
service orientated architecture200. The individual related technologies are listed in chapters
8 and 9201.
Under Observation:
Business Process Execution Language for Web Services (BPEL4WS)
v1.1
BPEL4WS202 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 such as Oracle, Microsoft, IBM, SAP, BEA and
Siebel support the specification and tools, including Open Source203, are also available.
BPEL4WS, however, is not yet an official (OASIS) standard. The further development of
BPEL4WS is being carried out under the name Web Services Business Process Execution
Language (WS-BPEL) v2.0.
Under Observation:
8.7.4 Access to databases
Mandatory:
Java Database Connectivity (JDBC) v3.0
JDBC204 should be used for access to databases.
199. Refer to http://www.w3.org/TR/ws-arch/
201. With regard to XML, refer to section 8.2.3 "Interchange formats for data" on page 75; with regard to SOAP,
WSDL and UDDI, refer to section 8.6.1.2 "Client-to-server communication" on page 96; with regard to WS security, refer to section 9.5.5 "Web Services" on page 116
202. Refer to http://www.oasis-open.org/committees/wsbpel/
203. Refer to http://www.bpelsource.com/products/
204. Refer to http://java.sun.com/products/jdbc/
page 102
8.8
Long-term archiving
With the growing distribution of electronic documents in administrations, sustainable and
long-term storage requires standards for storage which warrant the authenticity and completeness of the documents.
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 field of application which is why the properties of the "Baseline TIFF" must be used without exception; refer also to section 8.5.1.14 on
page 88.
Recommended: Joint Photographic Experts Group (JPEG)
JPEG205 can be used to store colour and grey-value images. 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 should be used for long-term
archiving of images, in particular, for photos. JPEG is not suitable for graphics with similar
colour surfaces and strongly contrasting colour transitions (example: characters).
XML is suitable for long-term archiving, however, the related schemas and XSL files must
also be archived, refer to section 8.2.3 on page 75. Examples of XML-based languages for
long-term archiving include Encoded Archival Description (EAD)206, Encoded Archival Context (EAC)207 and Metadata Encoding and Transmission Standard (METS)208.
Recommended: ArchiSig, principles for conclusive and secure long-term archiving of
electronically signed documents
The ArchiSig209 project was carried out by various participants from the worlds of science,
industry and users under the leadership of Informatikzentrum Niedersachsen [Lower Saxon
Computer Science Centre] and Staatliche Archivverwaltung Niedersachsen [Lower Saxon
state archive administration]. It defines principles210 that should be observed for the longterm archiving of electronically signed documents.
205. Refer to http://www.jpeg.org/index.html?langsel=de
206. Refer to http://www.loc.gov/ead/
207. Refer to http://jefferson.village.virginia.edu/eac/
208. Refer to http://www.loc.gov/standards/mets/
209. Refer to http://www.archisig.de/
210. Refer to http://www.archisig.de/grundsaetze.pdf
page 103
Under Observation:
Portable Document Format Archive - 1 (PDF/A-1)
The ISO PDF/A211 standard (ISO 19005-1:2005) is based on PDF v1.4, refer to section 8.5.1.8
on page 85 with the restrictions that fonts are embedded and metadata is captured. No
passwords, executable code or audio or video data may be embedded. The standard
should be used for the long-term archiving of text and presentations. This standard recognised by ISO can be used to save document contents, document form and the metadata of
the document in one archived file. The file can also be displayed without the original application. A presentation of contents for the disabled is also provided.
Under Observation:
211. Refer to http://www.adobe.de/products/acrobat/pdfs/pdfarchiving.pdf
page 104
9 Technology viewpoint (part II): data security standards
Ensuring data security is a major aspect for the successful implementation and performance of online services. Data security represents and supports trusted and secure interaction between citizens, public authorities and business.
The eGovernment architecture model, refer to chapter 3, identifies data security as an
omnipresent component which can be supported - as demanded or required - by suitable
processes, methods and data formats in every element and every pillar of the model. Technical means must be used to ensure that trust is created among those who communicate
with each other, that baseline protection is ensured and that classic protection aims are fulfilled.
As the relevance of security measures has increased enormously in recent years due to the
growing use of the Internet, standardisation efforts have also increased in this area. The
result is a host of security standards, directives and recommendations.
This chapter introduces the relevant security standards and recommendations for eGovernment services.
9.1
Determining protection requirements
The data security standards presented here help determine whether an IT application,
including the data processed, requires protection. Only when a need for protection is identified will it be necessary to take protective measures.
Mandatory:
BSI-Standard 100-2: IT baseline protection approach v1.0
In December 2005, the German Federal Office for Information Security (BSI) published its
"BSI-Standard 100-2: IT baseline protection approach"212. This standard precisely describes
the approach for determining protection requirements which was formerly presented in
the IT Baseline Protection Manual (IT-GSHB).
The identification of a risk and counteractive measures are summarised in the BSI's IT Baseline Protection Catalogues213.
9.1.1 Protection aims
Protection aims define the security interests of communication partners in a general form:
a. Confidentiality – protection against disclosure to unauthorised parties:
no data is made available or disclosed to unauthorised individuals, entities or processes.
Confidentiality is ensured by encrypting the information (cryptography).
page 105
b. Integrity – protection against manipulation:
unauthorised 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).
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 authorised entity.
A high degree of availability is achieved through multiplicity, distribution and error tolerance.
9.1.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 caused by impairment
of the IT application in question with regard to the protection aims defined in section 9.1.1.
A protection requirement category can be assigned to every protection aim in order to evaluate applications from a security point of view. The "BSI-Standard 100-2: IT Baseline Protection Approach" contains the following categories:
Protection requirement categories
"Normal"
The impact of any loss or damage is limited.
"High"
The impact of any loss or damage may be considerable.
"Very high"
The impact of any loss or damage can reach catastrophic proportions and could threaten the very existence of the agency/company.
Tabelle 9-1: Protection requirement categories
One aspect to be particularly 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 e-government manual
(module: Data-protection-compliant eGovernment214) contains data protection information with regard to frames of reference, challenges and recommended actions.
9.2
Security concept
Laws and resolutions of the Federal Government must be generally considered to be mandatory. These laws and resolutions are supplemented by recommendations and directives
for IT security.
The recommendations and guidelines by the German Federal Office for Information Security (BSI) and the Co-operation Committee for Automatic Data Processing for the Federal
Government, Federal-state Government and Municipal Administration Sector (KoopA ADV)
214. Refer to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter II, module "Data-protection-compliant eGovernment"
page 106
should be used to determine protection requirements. If an IT application or component is
found to require protection, adherence to these recommendations and guidelines is mandatory.
Mandatory:
BSI-Standard 100-1: Management systems for Information Security (ISMS)
v1.0
BSI standard 100-1215 with the general requirements for ISMS 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 17799.
Mandatory:
BSI-Standard 100-2: IT baseline protection approach v1.0
BSI standard 100-2216 with the description of how IT security management can be established and operated in practice should be applied within the scope of the security concept.
With this approach, IT security concepts can be created, simply and - in terms of the work
involved – economically, whilst IT security can be maintained and improved in ongoing
operations.
Mandatory:
BSI-Standard 100-3: Risk analysis on the basis of IT baseline protection
v2.0
BSI standard 100-3217 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. 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.
Mandatory:
BSI, IT Baseline Protection Catalogues
The BSI's IT Baseline Protection Catalogues218 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 and economically in terms of the work required.
Recommended: KoopA ADV, Guideline for the Introduction of the Electronic Signature
and Encryption in the Administration v1.1
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
page 107
Federal Government, Federal-state Government and Municipal Administration Sector
(KoopA ADV)219 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.
Recommended: BSI, eGovernment manual
BSI's eGovernment manual220 was created, for instance, in order to support the BundOnline 2005 initiative which has now been completed. The manual contains organizational
and technical recommendations concerning the use of IT in eGovernment applications.
Security-related recommendations are one of the central features.
9.3
Implementation of the security concept
ISIS-MTT v1.1221 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).
Mandatory:
Industrial Signature Interoperability Specification - MailTrusT (ISIS-MTT)
v1.1
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 compliance 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. The basis of ISIS-MTT
is a core specification which is mandatory for all manufacturers and suppliers and which
can be supplemented by optional profiles as required. The "SigG Profiles" and "Optional
Enhancements to the SigG-Profile" profiles which are 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 by
the certification authority (PKCS#7)
3. Setting up encrypted and signed messages
219. Refer to http/www.koopa.de/projekte/pk.html
221. Refer to http://www.isis-mtt.org/
page 108
4. Requests for public-key certificates, attribute certificates and certificate revocation lists
using LDAP, OCSP, 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
9.4
Basic technology
This section describes the technologies which are generally needed to implement IT security.
9.4.1 Technologies for authentication
In order to ensure that protection aims of confidentiality and integrity are achieved, certain
eGovernment applications require the identification and authentication of communication
partners.
Mandatory:
BSI, 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 "Authentication in e-government"222 module
of the 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
SAML223 is an XML-based format for exchanging authentication information. The exchange
of data in a uniform format especially promotes interoperability between eGovernment
applications. Version 2.0 was published in March 2005.
Under Observation:
Kerberos v5
Kerberos224 is a protocol for authentication in computer networks that was developed by
the Massachusetts Institute of Technology (MIT). Interoperability is promoted through the
uniform exchange of authentication data. However, operating-system dependent expansions do sometimes lead to incompatibilities between different implementations.
222. Refer to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter IV B, module
"Authentication in eGovernment"
223. Refer to http://www.oasis-open.org/specs/index.php#samlv2.0
224. Refer to http://web.mit.edu/kerberos/
page 109
9.4.2 Connection to a security infrastructure
The security infrastructure includes directory, certification and time-stamp components
which support the distribution and handling of certificates, revocation lists and time
stamps both for e-mail as well as for web environments. Access to these components takes
place via operational protocols.
Mandatory:
v1.1, Part 4
Part 4 of ISIS-MTT describes "Operational Protocols", i.e. protocols or rather profiles for connecting to security infrastructures, refer to section section 9.5.2 "Securing e-mail communications" on page 114. These include access to directories via LDAP v3, Online Certificate
Status Protocol (OCSP), FTP and HTTP as well as the Time Stamp Protocol (TSP).
9.4.3 Connecting smartcards
Integration of smartcards, smartcard readers and their driver architectures and/or complex,
multi-function "Smartcard / reader bundles" is, for example, necessary in order to use qualified electronic signatures in conjunction with the client infrastructure.
The D21 initiative225 addressed this issue through its working group 5 – "Smartcards project". The results were compiled in a project report 226.
Mandatory:
ISO/IEC 7816
Smartcards (chip cards) must comply with the ISO/IEC 7816 standard. Components supporting the universal "Cryptographic Token Interface" (Cryptoki) must comply with ISIS-MTT
v1.1, Part 7 (Cryptographic Token Interface).
9.4.4 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 standardised mechanisms must be used to read and write data.
Recommended: XML Key Management Specification (XKMS) v2
XKMS227 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).
225. Refer to http://www.initiatived21.de/
226. Refer to http://www.initiatived21.de/druck/news/publikationen2002/doc/28_1053503411.pdf
227. Refer to http://www.w3.org/TR/xkms2/
page 110
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.
9.4.5 Electronic signature
The security of an electronic signature is primarily dependent upon the strength of the
underlying cryptographic algorithms. Concerning the "electronic signature" issue, refer also
to section 4.1.5.1 on page 39.
Mandatory:
Cryptographic algorithms for the electronic signature according to the
Federal Network Agency
Every year, the Federal Network Agency228 publishes in the Federal Gazette those cryptographic algorithms which can be considered as suitable at least for the next six years with a
view to the requirements of the German Signature Act (SigG) and the Digital Signature
Ordinance (SigV). To this effect, the minimum dimensions of parameters, such as block size
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.
9.4.5.1 Hashing data
A hash function reduces the data to be signed to a hash value, 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), 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.
Recommended: Secure Hash Algorithm (SHA)-224 / Secure Hash Algorithm (SHA)-384 /
Secure Hash Algorithm (SHA)-512
SHA-224, SHA-384 and SHA-512 (Secure Hash Algorithm), as further developments of
SHA-1 (160-bit long hash value), are cryptographic hash functions that generate longer
hash values (the length corresponds to the number stated).
Recommended: RIPE Message Digest (RIPEMD)-160
RIPEMD-160 is a cryptographic hash function which generates hash values with a length of
160 bits.
228. Refer to http://www.bundesnetzagentur.de/
page 111
9.4.5.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
RSA was developed by Ronald L. Rivest, Adi Shamir and Leonard Adleman. The RSA method
is the most important asymmetric method. It is also termed public key method. The security
of this method is based on the difficulty to factorise large natural numbers. Normal key
lengths are 1024, 2048 and 4096 bits.
Recommended: Digital Signature Algorithm (DSA)
The Digital Signature Algorithm (DSA) is a signature method which was developed and specified in 1991 in the US Digital Signature Standard (DSS). 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.
9.4.6 Encryption
Cryptographic algorithms for encryption can be applied to data and/or keys in order to
ensure their confidential transmission.
9.4.6.1
Asymmetric encryption methods
Asymmetric encryption methods are, for example, required in order to exchange a socalled session key between communication partners. A session key is a symmetric key, refer
to section 9.4.6.2 on page 112.
Mandatory:
RSA
RSA is used during encryption just like signing, refer to section 9.4.5.2 on page 112. 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.
9.4.6.2
Symmetric encryption methods
Symmetric methods, when applied, use the same private key for encryption and decryption. These methods usually feature very high performance.
page 112
Mandatory:
Advanced Encryption Standard (AES)
AES229 is a symmetric block cipher with a defined 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)230.
The Triple Data Encryption Standard (Triple-DES, also called 3DES), which was still recommended in SAGA version 2.1, has been moved to the Grey List.
9.5
Applications
In order to enable a realistic assignment of security standards, frequently encountered
applications are formulated from a security point of view.
9.5.1 Secure transmission of data and server authenticity
When a client communicates with the server of a public agency, measures must be taken to
ensure that communication really takes place with this server (server authenticity). The
retrieval of information, i.e. the transmission of contents, for which integrity and/or confidentiality is required, must be accomplished in a secure manner during transmission on the
Internet.
Mandatory:
Transport Layer Security (TLS) v1.0
TLS231 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,
has been moved to the Grey 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 WWW 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.
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
229. Refer to http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
230. Refer to http://csrc.nist.gov/
231. Refer to http://tools.ietf.org/html/rfc2246
page 113
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)232. 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.
Under Observation:
Transport Layer Security (TLS) v1.1
Adopted in April 2006, TLS v1.1233 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.
Recommended: Secure Shell v2 (SSH-2)
The SSH-2 protocol is an enhanced version of the SSH which has existed since 1995. Using a
standardised 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.
9.5.2 Securing e-mail communications
The secure exchange of e-mails is one possible application for the "communication" interaction stage. Secure e-mail communication includes the securing of e-mails during their
transmission from a sender to a recipient. This application looks at e-mails in their entirety.
The section on "Secured document exchange" deals with the procedures for securing documents, including e-mail attachments.
Mandatory:
v1.1, Parts 1 to 6
The ISIS-MTT specification considers a host of applications for processes to secure electronic business (for example, file, mail, transaction and time "protection") on the basis of the
basic functionalities, i.e. electronic signature, encryption and authentication, refer to
section 9.3 on page 108.
Parts 1 to 6 are especially relevant for securing e-mail communications.
232. Refer to http://www.koopa.de/projekte/pki.html
233. Refer to http://tools.ietf.org/html/rfc4346
page 114
9.5.3 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.
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 becoming increasingly
relevant for the secure exchange of XML documents (e.g. for forms designed for further
processing).
Mandatory:
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)234 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 Recommendation)235 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.
Contrary to XML Signature, XML Encryption is not an RFC, however, together with XML Signature it is the foundation for several standards accepted in the industry for secure XMLbased document exchange (Web Services Security, SAML, ISIS MTT, ebXML-Messaging,
FinTS, OSCI-Transport).
234. Refer to http://www.w3.org/TR/xmldsig-core/
235. Refer to http://www.w3.org/TR/xmlenc-core/
page 115
9.5.4 Transactions
Transactions cover the complex, specialised business cases with a multi-stage value chain
between communication partners.
Mandatory:
Online Service Computer Interface (OSCI)-Transport v1.2
The Online Service Computer Interface (OSCI)236 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 jeopardising confidentiality at the business case data level is a characteristic feature for the secure implementation of eGovernment processes using OSCI. As a
secure transmission protocol, it enables binding online transactions (even in conformity
with 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 standardises
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).
9.5.5 Web Services
The growing importance of XML as a data interchange and specifications format even in
the security area as well as the introduction of web services as integrative middleware are
leading to the active standardisation of XML security standards by W3C and OASIS specialists.
Recommended: Web Services (WS)-Security v1.1
WS-Security237 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
236. Refer to http://www.osci.de/
237. Refer to http://www.oasis-open.org/specs/index.php#wssv1.1 and http://www.oasis-open.org/specs/index.php#wssprofilesv1.0
page 116
encryption of SOAP messages based on XML Signature and XML Encryption. The use of different security models and different cryptographic methods 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
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.
page 117
page 118
Appendix A One-for-all offers
Reusable basic modules were developed to support the BundOnline 2005 Initiative. The
implementation of the more than 400 Internet-enabled services was supported by socalled basic components, infrastructure components and one-for-all services (OFA services). These basic modules are now generally referred to as one-for-all offers (OFA offers).
When the initiative came to an end in 2006, responsibility for the OFA offers was passed on
to the Co-ordinating and Advisory Agency of the Federal Government for Information
Technology in the Federal Administration (KBSt). In anticipation of a state-of-the-art, service oriented architecture concept, the OFA offers were re-grouped and broken down into
OFA services, OFA systems and infrastructure. The term "OFA services" ("EfA-Dienst" in German as opposed to the old term "EfA-Dienstleistung") now interprets "service" as in "Service
Oriented Architecture"238. Though both terms translate to "OFA service" the concepts are
quite different.
Formerly:
Terminology of the
BundOnline 2005
initiative
Basic
components
• ePayment
• Form server
•…
New:
Terminology
since 2006
Basic modules
Infrastructure
components
• IVBV
• Directory service
•…
OFA
services
• profi
• eTendering
•…
OFA offers
OFA services
• ePayment
• Directory service
•…
OFA systems
• Form server
• profi
• eTendering
•…
Infrastructure
• IVBV
•…
Figure A-1: Use of new terms and groupings
In line with the new grouping, SAGA 3.0 describes the former basic components and infrastructure components and includes the new OFA offers for geo-applications. In future, the
former one-for-all services (OFA services) will be described and updated in the new grouping, together with all other OFA offers, on the KBSt239 homepage.
239. Refer to http://www.kbst.bund.de/
page 119
The OFA offers provide functionality blocks which are part of many different services and
which can be used as services, systems or infrastructure in eGovernment applications. The
services and technology platforms were mostly developed for one public agency and are
then widely used in the federal administration - sometimes with an identical configuration
or with a demand-orientated configuration. Existing OFA offers are further developed
under the KBSt's leadership. Moreover, new offers are identified which have a high potential for reuse.
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.
The following OFA services are described in SAGA 3.0:
a. Payment platform ("ePayment")
b. Directory service
c. GeoDataCentre (GDZ)
An OFA system is a uniform entity, a software entity, that makes a complex functionality
available. OFA systems include the following:
a. Data security ("Virtual Post Office" – VPS)
b. Form Management System (FMS)
c. Content Management System ("Government Site Builder" – GSB)
d. Portal bund.de
e. GeoPortal.Bund
In addition to OFA services and OFA systems which directly take over sub-processes from
eGovernment applications, infrastructures are also made available. Although the services
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 introduced as infrastructures in SAGA:
a. Federal Administration Information Network (IVBV)
b. Administration Public Key Infrastructure ("Administration PKI")
If the business cases described below are suitable for an eGovernment application, the
respective OFA offers should be used. Alternative means of implementation for functionality blocks covered by OFA offers should only be adopted in justified, exceptional cases.
A.1 OFA service - Payment platform ("ePayment")
A.1.1 Introduction
The range of services covered by the Payment Platform (ZVP) as a one-for-all service (OFA
service) currently includes to a large extent the import of debit entries from the different
Internet-based applications, eShops and workflow management systems using web services, the validation of and passing on of these entries to the payment monitoring system
(ZÜV) right through to subsequent budget-related posting in the system of the Federal
page 120
Budgeting and Accountancy Service (HKR). This can involve prices for goods or also fees for
services.
Contact in matters related to
development, operation and
competence centre
Mr Volker Walgenbach
ePayment@bff.bund.de
Zentrum für Informationsverarbeitung und
Informationstechnik (ZIVIT)
Postfach 30 16 45
53196 Bonn
Tel.: +49 1888 680 - 5905
Fax: +49 1888 680 - 5241
Homepage, FAQ / Documentation
https://epay-integration.bff-online.de/doku/
Login and password can be obtained from the
contact person or by sending an e-mail to:
ePayment@bff.bund.de.
A.1.2 Functionality description
A.1.2.1 Overview
The payment platform supports the following payment methods.
a. Direct debit
b. Bank transfer
c. Credit card
The following section will discuss the individual methods in more detail for the different
business cases.
The OFA service solely handles the revenue end of Internet-based transactions. Payments
still use conventional methods. Revenue orders received by the ePayment service are automatically passed on to the payment monitoring system (ZÜV) where they are represented
by conventional debit posting.
After the financial year has come to an end, settled files are transferred to the history and
are no longer actively available. In the case of payment partner accounts or in the case of a
payment falling due at the end of a year, the debit entry remains also during the following
financial year. Micropayments, i.e. the process of accumulating debit entries up to a certain
amount, are not considered because the Federal Budget Code (BHO) demands immediate
collection of such amounts.
Business processes where payment is just one of several modules must be developed from
within the special applications. In line with the specific nature of such processes, the
payment platform must then be integrated into the special method. The ePayment project
group operates a competence centre offering consultancy services and advice on all issues
related to electronic payments. To this effect, experience from previous projects is gathered
and made available.
page 121
Section A.1.3 "Interfaces" describes a reference implementation for integrating the OFA
offer into special processes.
A.1.2.2 Business cases
eGovernment applications primarily use the browser as the front-end, unless the services to
be implemented cannot be reasonably handled via a browser.
Some of the following business cases include an address and solvency check. The OFA service partly relies on external service providers which offer online checks. The address check
ensures that an address really exists. The solvency check includes, for example, a plausibility
check of the account number and bank code, the analysis of open invoices, the volume of
invoices paid and reverse entries, if any. As a result, a customer can, for example, be granted
a higher purchasing volume or allowed to pay after delivery. The special applications can
individually configure the test steps and their performance from case to case.
Bank transfer prior to delivery
Prepayment by bank transfer is a secure method of payment and hence particularly suitable for large-sum payments.
a. Registration of the customer with the customer's e-mail address or another unambiguous feature for service of the bill.
b. The customer fills the shopping cart and optionally states a delivery address.
c. The application sends the bill to the customer.
d. The application transmits the data necessary for the debit entry either in cycles (for
example, once a day) or immediately online. Once a day, the ePayment server sends the
data of all the bank transfers to be expected to the payment monitoring system (ZÜV
system).
e. The customer pays the bill.
f.
The payment monitoring system (ZÜV system) informs the ePayment server that the bill
has been paid.
g. The application retrieves the recent payment information from the ePayment server in
cycles (for example, once a day).
h. The application ships the goods or renders the service.
Bank transfer after delivery
This form of payment is commonly used in mail order business. It is particularly suitable for
the physical shipment of products or for rendering services. The suitability of this system for
electronic downloads must be examined from case to case.
page 122
6. Shipment of goods and invoice
1. Customer registration
Customer
5. Customer fills
shopping cart
9. Customer
pays invoice
2. Customer
registration
7. Transmission
of debit entry
Bank
Bank
€
€
Solvencycheck
Special application
Internet
11. Query of
payments
received
ePayment
4. Confirmation of
registration
3. Check of
customer data
8. Transmission of
all debit entries
HKR / ZÜV
10. Reporting
payment received
Figure A-2: Bank transfer after delivery with the ePayment OFA
Collection by electronic direct debit
Direct debit is a very popular form of payment in Germany and is widely used on the Internet. This method is a suitable form of payment for once-off services and for goods shipped.
The amount due is collected when due. The "Repeated direct debit with direct debit" form
of payment should be adopted for recurring payment processes.
Checks are vital because users can submit incorrect account information and there is a risk
of payments being re-debited. In view of the risks for the special application, this method is
not suitable for larger amounts. It is left to the discretion of every special application at
what level it determines the upper limits for the different solvency levels.
a. Registration of the customer with the customer's address data for identification as well
as account information
b. Immediate check of the complete customer information
c. The customer fills the shopping cart.
d. (Either immediately or after receipt of payment), the application ships the goods or performs the service and sends the bill to the customer.
e. The ZÜV system collects the amounts due.
f.
The ZÜV system informs the ePayment server that the bill has been paid.
g. The application retrieves the recent payment information from the ePayment server in
Repeated direct debit with direct debit
This method is particularly suitable when it comes to collecting fees for recurring services.
This payment method is relatively secure because the customer signs a direct debit form
page 123
which can be submitted to the bank should a re-debit occur. It is left to the discretion of
every special application at what level it determines the upper limits for the different solvency levels.
Since the authorisation process takes several days when used by a customer for the first
time, the special application should be capable of storing a shopping cart over a longer
period of time.
a. Registration of the customer in order to be able to assign the direct debit authorisation
to the customer at a later time
b. The customer fills the shopping cart.
c. If direct debit authorisation was already issued to the special application, step f follows.
d. The customer grants direct debit authorisation once and sends it by post.
e. The customer's PIN is sent once by post.
f.
The customer uses the PIN to confirm the payment process for the goods and services
in the shopping cart.
g. (Either immediately or after receipt of payment), the application ships the goods or performs the service and sends the bill to the customer.
h. The amount due is debited to the customer's account and credited to the Federal
Government's account.
i.
The ZÜV system informs the ePayment server that the bill has been paid.
j.
The application retrieves the recent payment information from the ePayment server in
Credit card
a. Registration of the customer; address information is not absolutely necessary with this
form of payment.
b. Address verification can be carried out if goods are delivered or services rendered
immediately.
c. The customer fills the shopping cart.
d. The application checks the credit card information, including the Card Verification Code
(CVC), and sends this information to the ePayment system for debiting the credit card.
e. (Either immediately or after receipt of payment), the application ships the goods or performs the service and sends the bill to the customer.
f.
The ePayment and the ZÜV system jointly settle the bill, i.e. collect the amount due.
g. The ZÜV system informs the ePayment server that the bill has been paid.
h. The application retrieves the recent payment information from the ePayment server in
A.1.3 Interfaces
The payment platform is implemented using central web services. These are so far the following services.
page 124
a. Customer data management
b. Bank search
c. Bank transfer methods
d. Direct debit payment methods
e. Credit card payment methods
f.
Paypage
g. Report
The project group provides reference implementations, for instance, in Java which enable
integration of the OFA service into a local special application or eShop. The implementation
includes all the necessary SOAP interfaces, including serialisers and deserialisers. Opensource libraries were used for implementation throughout. Integration into commercial
shop systems, such as Intershop Infinity, should be possible.
For more information, please go to: http://www.zivit.de/.
A.1.4 Operation
The ePayment OFA service is provided centrally. Time-consuming and costly process analyses are not necessary for the individual special applications. The special application is connected to the ePayment system via an encrypted connection by calling the web services
available.
A.1.5 Reference projects
A selection of reference projects:
a. German Institute for Medical Documentation and Information (DIMDI) – webshop240
b. Federal Institute for Materials Research and Testing (BAM) – webshop241
c. Federal Administrative Court (BVerwG) – mailing of court decisions242
d. Federal Agency for Nature Conservation (BfN) – CITES special applications243
e. Helmut-Schmidt-Universität Hamburg (Bundeswehr (Federal Armed Forces) university)
– eLearning244
f.
Federal Maritime and Hydrographic Agency (BSH) – Workflow management 245
A.1.6 Outlook
Version 1.18 of the payment platform OFA service is available for productive operation.
Major upgrades are currently not planned. The pertinent competence centre ensures maintenance, service and operation. Work on connecting special eGovernment applications to
240. Refer to http://www.dimdi.de/
241. Refer to http://www.bam.de/
242. Refer to http://www.bverwg.de/
243. "Registration for the import and export of protected animal and plant species", refer to http://www.cites-online.de/
244. Refer to http://www.hsu-hh.de/
245. Refer to http://www.bsh.de/
page 125
the ePayment system is currently underway. Within this framework, the OFA service will be
continuously developed further in order to consider and address new requirements.
For the latest information, please go to: http://www.zivit.de/.
A.2 OFA service – Directory service
A.2.1 Introduction
The one-for-all directory service (OFA service) provides a directory based on the X.500 standard via the Berlin-Bonn Information Network (IVBB) and the Federal Administration Information Network (IVBV). Agency-spanning address information, telephone numbers,
addresses, e-mail addresses, etc. are made available to the users, typically public agencies,
connected to the IVBB and IVBV. This service is designed to facilitate communication between public agencies.
Information concerning the participating public agencies and their employees is stored in
the directory service on the IVBB and IVBV intranets. Only address information from the
IVBB directory service released by the public agencies is provided in the IVBV. The data
records from the IVBV are completely mirrored in the IVBB. IVBB and IVBV users can access
the directory service using LDAP-v2/v3 clients. IVBB users can additionally view the data
using web browsers. The advantage of the directory service for public agency staff is that
the data is guaranteed to be up to date without staff having to carry out time-consuming
updates.
The directory service is also available on the Internet246. Data records of the X.500 directory
are mirrored from the intranet into the Internet with reduced content. The public agencies
decide which address data is to be available on the Internet. The IVBB currently contains
77,594 entries and 4,191 certificates.
Contact partner for matters related to Dr. Christian Mrugalla
development
it2@bmi.bund.de
Bundesministerium des Innern
10559 Berlin
Tel.: +49 30 18 681-4326
Fax: +49 30 18 681-54326
246. Refer to http://x500.bund.de/
page 126
Contact partner for matters related to Mr Wilfried Kister
operation
Referat112@bsi.bund.de
Bundesamt für Sicherheit in der Informationstechnik
Postfach 200363
53133 Bonn
Tel.: +49 30 18 9582-5366
Fax: +49 30 18 10 9582-5366
Homepage
http://www.kbst.bund.de/saga-x500
http://x500.bund.de/
FAQ / Documentation
http://x500.bund.de/doc/x500faq.html
http://x500.bund.de/doc/hilfe.html
A.2.2.1 Overview
Several options exist for making data available in the directory service.
a. Users with a directory system of their own can take part in the distributed X.500 directory (used here as a synonym for directory service). How and in what form the servers
communicate must be decided from case to case.
b. If the user does not have access to a directory system of his own, a data interface is implemented via which data can be imported into the central X.500 directory.
The directory service on the intranet and on the Internet is operated by the company T-Systems. T-Systems administers the integration of the distributed directories and is responsible for importing data via the file interface as well as for schema modifications and/or
amendments.
The data model in the X.500 directory features a hierarchical structure. The topmost node
that can be administered is c=de, o=bund, with c=de representing country=Germany and
o=bund meaning organization=federal government. Data administration is only possible
below this node, i.e. the "administrative point".
The objects supported in the directory service are enumerated below.
a. Public agencies – being the supreme federal authorities and other agencies (ministries,
organizations). They are stored as "organizationalUnit" in the directory.
b. Sites and locations – these are stored as "locality" in the directory.
c. Individuals, but also organizational units – these are stored as "inetOrgPerson" in the
directory.
d. Rooms – these are stored as "room" in the directory.
e. Departments (or units) – are stored as "ivbbDepartment" in the directory.
f.
Certification Authorities (CAs) – are stored as "applicationProcess" in the directory.
page 127
Standard application
A user at a public agency needs the e-mail data of a recipient at the user's agency or at another public agency. The application, for example, Outlook, accesses the e-mail data from
the X.500 directory in order to offer possible addresses.
As a precondition for this, the individual's name must be stored in the X.500 directory and
the data must be complete (central synchronisation of the X.500 data).
Basic application
The public agency makes its address data available to other public agencies and users outside public agencies. Distributed data updating and central distribution are supported.
A.2.3 Interfaces
Although the structure of the X.500 schema is largely orientated towards the X.509, X.520,
X.521 (1997, 2000), X.402 (1988), RFC 1274 (COSINE / Paradise), RFC 2256 (X.500 Schema for
LDAP v3) and RFC 2798 (inetOrgPerson) standards, numerous additions, especially attributes, have been made which can be checked at the web address stated in section A.2.1
"Introduction" on page 126.
A.2.4 Operation
A.2.4.1 Central operation
a. Availability: 99.43%
b. Maximum number of entries: 1,000,000
c. Maximum quantity of results: 250
A.2.4.2 Local operation
The directory service is designed as a central OFA offer. This offer can be used merely by
accessing the respective network (IVBB / IVBV or Internet, respectively) via the web and/or
e-mail.
The following is required for local operation:
a. Standard web browsers (e.g. Firefox, Microsoft Internet Explorer)
b. or LDAP-enabled software (e.g. KDE Kontact, Microsoft Outlook)
The directory service has been in effective operation since 1998. It is "routinely" used both
within and outside the federal administration.
page 128
A.2.6 Outlook
A ministry-spanning working group is currently examining to what extent the functionalities of the central directory service can be integrated into a conceivable, future agencyspanning identity management system of the federal administration.
A.3 OFA servcie - GeoDataCentre (GDZ)
A.3.1 Introduction
The services offered by the GeoDataCentre (GDZ) one-for-all service (OFA service) include
standardised web services for researching, providing and processing topographic maps
and digital topographic landscape models (basic geo-data) along with information concerning the availability and quality of the data and services (metadata).
Contact person for matters related to
development and the competence centre
Dr. Manfred Endrullis
Manfred.Endrullis@bkg.bund.de
Bundesamt für Kartographie und Geodäsie
Außenstelle Leipzig
Karl-Rothe-Str. 10 – 14
04105 Leipzig
Tel.: +49 341 5634-369
Fax: +49 341 5634-415
Contact partner for matters related to
operation
Mrs Andrea Kratochvil
Andrea.Kratochvil@bkg.bund.de
Außenstelle Leipzig
Karl-Rothe-Str. 10 – 14
04105 Leipzig
Tel.: +49 341 5634-408
Fax: +49 341 5634-415
Homepage
http://www.geodatenzentrum.de/
A.3.2.1 Overview
The meta-information system and the related catalogue service provide information on the
basic geo-data (including topographic data from the German geodatic service) available
from the Federal Centre for Cartography and Geodesy.
For instance, all official topographic maps and digital topographic landscape models of
Germany are available in graphic form via Web Map Services (WMS):
page 129
a. Digital topographic maps at a scale of 1:25,000, 1:50,000, 1:100,000, 1:200,000,
1:500,000 and 1:1,000,000
b. Digital landscape models at a scale of 1:25,000, 1:250,000 and 1:1,000,000
c. Digital terrain models
d. Administrative boundaries, postcode districts and geo-referenced postal addresses
Web Feature Services (WFS) will be gradually introduced in order to provide object-structured basic geo-data from the Official Topographical-Cartographical Information System
(ATKIS). A first service is ready for use for the Geographical Names in Germany (GN-DE) data
stock.
Furthermore, a service for online co-ordinate transformations is to be offered, along with an
addressing service (geo-referencing of postal addresses), as well as a service for historical
place names (for all territories that once belonged to Germany).
The GeoDataCentre services can be used via web browsers to visualise data or for simple
research. The services can also be integrated into local geo-applications for joint evaluations with special data. Furthermore, basic geo-data will also be offered for download so that
this data can be subsequently used offline in separate applications. Finally, processing services, such as co-ordinate transformation or addressing, receive user information, process
this and send the result of processing back to the user so that it can be integrated into the
user's workflows.
Searching in meta-information of German geo-data
The meta-information system serves as a graphic web application of the information on the
availability and quality of Germany's official basic geo-data. The related catalogue service is
the program interface for searching the data of this system. It can be used to exchange
meta-data and for automatic research, e.g. by broker systems such as the geo-data catalogue of GeoPortal.Bund247.
Online integration of topographic maps in eGovernment applications
The topographic maps, administrative boundaries, postal code districts, terrain models, etc.
provided as Web Map Services (WMS) offer direct graphic information which can be easily
used to show positions, to underline special geo-data and for visual evaluation. The integration of the respective services can take place in the user's website or in local applications
– without having to locally administer the basic geo-data itself.
Analysis and integration of geographical data
Web Feature Services (WFS) such as the Geographical Names in German (GN-DE) service
offer direct access to object-structured data together with their location geometry and
attributes. This means that electronic analyses are possible, such as combining of special
247. Refer to section A.8 "OFA system - GeoPortal.Bund" on page 156
page 130
geo-data with basic geo-data in order to determine geographical and thematic contexts.
Contrary to the WMSs, this data must be visualised at the client end.
Searching for historical places
The historical place name service provides information on the names and nationality of
places that once belonged to Germany since 1900. Apart from the service that can be integrated into the user's applications and which was specially developed for processing issues
of citizenship by the BVA, a web application is also available.
Transformation between co-ordinate reference systems
The online co-ordinate transformation service permits special users to transform from individual co-ordinates or entire co-ordinate files between the co-ordinate reference systems
customary in Germany. This is frequently an important aspect when processing objectstructure geo-data of different origins.
Offline integration of geo-data in eGovernment applications
Federal institutions can also directly download data at all times which can be used both
locally and offline in applications.
Addressing service
The addressing service permits the assignment of location co-ordinates to postal addresses
(geo-referencing). Nation-wide searching for address information and the identification of
its geographical location on a town, postcode, street and house-number level is offered.
The service is particularly suitable for special applications where the only position indication available is an address.
A.3.3 Interfaces
CS, WMS and WFS-type services are based on international HTTP interfaces which are defined by the Open Geospatial Consortium (OGC) and the International Organization for Standardization (ISO)248. A separate interface specification was initially used for co-ordinate
transformation because no international standardisation results were yet available at that
time. A separate interface specification was also created for the historical place names service in order to offer special functionalities 249.
A.3.4 Operation
The OFA service is provided centrally. Local data storage, own visualisation services or own
processing services may not be available to some special users, depending on how the services are used.
248. With regard to the specifications of the OGC interfaces, please refer to: http://www.opengeospatial.org/
specs/
249. With regard to the specifications of the two interfaces, please refer to: http://www.geodatenzentrum.de/
page 131
The GeoDataCentre of the Federal Centre for Cartography and Geodesy maintains a scalable, powerful computer architecture with a redundant design (fail-over) to secure services.
The local use of central services requires a powerful network connection (at least DSL1000level). If a local geo-information system is used, this must support the previously mentioned international interfaces.
Only a standard web browser is needed for simple web applications. The web browser must
feature Java capability for powerful map displays.
The services were used in 2004/2005 for the online capture of the spread and supply level
of the digital voice and data radio network for the "BOS network" project at around 100
capture points located nation-wide.
The GeoPortal.Bund250 permanently uses a selection of services as a broker system.
A host of federal institutions permanently use the Geodata online download service.
In "Deutschland-Viewer"251 of the Federal Centre for Cartography and Geodesy, a selection
of services is continuously used together with distributed federal-state services.
The historical place names service is also used, for instance, by the Federal Office of Administration to clarify citizenship matters.
Other projects are currently being developed in co-operation with various federal institutions.
A.3.6 Outlook
The scope of the geo-data contents provided will be expanded further. This includes, in
particular, Web Feature Services (WFS) for all object-structured geo-data of the Official
Topographical-Cartographical Information System (ATKIS).
The services will be generally adapted to further developments of international standards
and attention will be paid to downward compatibility.
In addition to the services named, a web terrain service will be introduced in the medium
term for generating 3D terrain views based on topographic maps.
250. Refer to section A.8 "OFA system - GeoPortal.Bund" on page 156
251. Refer to: http://www.geodatenzentrum.de/
page 132
A.4 OFA system - Data security ("virtual post office")
A.4.1 Introduction
Developed as the BundOnline2005 basic component "Data security", the "virtual post
office" (VPS) one-for-all system (OFA system) centrally provides cryptographic services in
bundled form ("cryptography server") within a public agency.
It can be used:
a. to secure web-based (client-server) communication,
b. to secure e-mail communication and
c. to provide security functions for backend systems.
The VPS supports secure and legally binding communications between the public agency
and its communication partners (customers, i.e. other agencies, companies and citizens)
within the meaning of end-to-organisation communications. Parallel to this, end-to-end
mechanisms can be used wherever necessary.
Contact partner for matters related to Mr Thomas Gast
development
thomas.gast@bsi.bund.de
Postfach 20 03 63
53133 Bonn
Tel.: +49 1888 9582-5122
Fax: +49 1888 10 9582-5122
Contact partner for matters related to Central operation of the VPS as such is not foreoperation
seen. The precise modalities of operating a central
OCSP/CRL relay have not yet been defined (as of
June 2006).
Contact partner – competence centre Division 111
vps@bsi.bund.de
Postfach 20 03 63
53133 Bonn
Homepage, FAQ / Documentation
http://www.kbst.bund.de/saga-bk-vps
http://www.virtuelle-poststelle-bund.de/
page 133
A.4.2.1 Overview
The virtual post office serves as a central security gateway and communication server, offering security services via standardised interfaces for secure communications between
public agencies and external communication partners, such as other public agencies, citizens and businesses. To this effect, the virtual post office supports the special applications
in warranting the following security targets.
a. Confidentiality – of the information both transmitted and stored
b. Integrity – of the information both transmitted and stored
c. Binding effect – authenticity and demonstrability
d. Authentication – support for web-based and other applications with different authentication methods
The functional scope of the virtual post office also includes monitoring and logging.
Backend application
VPS
€
Web
documents
Internet
Citizens
@
§
Web/e-mail application
Business
E-mails
Public
agency
Security server
Web
gateway
Encrypt/decrypt
Check/make signature
Control
processing
Document
gateway
Check/make time
stamp
Check authentication
E-mail
gateway
Public
agency
Central services
such as virus and content check,
time server
Officer
Internet
Central
OCSP / CRL relay
External services
such as trust centre, PKI-1, PIN /
TAN, time stamp service
Figure A-3: Principle of the "Data security" OFA
The security functions enumerated below are made available to the eGovernment services
as uniform and – to the maximum extent possible – automatic functions via the interfaces
offered.
a. Encryption and decryption
b. Signature check and generation
page 134
c. Time stamp check and generation
d. Authentication on the basis of different credentials
The VPS can be connected to other systems, such as virus scanners, via open interfaces. This
makes it possible to implement more complex checks for documents and messages.
Besides indirect e-mail communication with a central address at public agencies, the OFA
system also supports strict end-to-end security with individual officers. This means that
inbound and outbound e-mails are then passed on without being changed and without
encryption or decryption. This is why individual features of the virtual post office can be
deactivated in a flexible manner.
In line with the varying requirements of the different special applications of a federal
agency, the central security gateway offers graded security mechanisms and algorithms.
Furthermore, standards and methods commonly used by citizens and business are also
supported, such as ISIS-MTT, SPHINX, PGP (in versions which support X.509 certificates) as
well as OSCI.
External trust centres communicate with the virtual post office via an OCSP / CRL relay. This
service is to be centrally provided for all federal authorities, but can also be operated locally
by a public agency. From the point of view of the individual public agencies, the advantage
of the central relay is that there is just a single, uniform interface for certificate information.
Expanding the original concept, the virtual post office provides a so-called OSCI enabler
which in the form of a distributed architecture supports OSCI communication on all three
levels (client – intermediary – backend) foreseen in the protocol252.
Prior to using the data security OFA system, every special application is responsible for classifying its protection requirements. The data security competence centre253 provides its
advisory services in this context. The competence centre has also developed a strategy for
the introduction of the virtual post office which is updated continuously.
A.4.3 Business cases
Every business case is accompanied by documentation of the relevant actions of the virtual
post office in the form of a VPS routing slip which is transmitted as an XML file. Access to
the data in inbound-mail and outbound-mail records which may exist outside the virtual
post office is restricted to administrators with special roles (supervision and audit). The preparation of such "records" is not a task for the virtual post office. At the agency end, there
are in principle two different ways of integrating special eGovernment applications. The
individual variant is where agency staff communicate with citizens with a suitable client via
an OSCI or SMTP mailbox. The automated variant is where a special application rather than
an employee is the communication end at the agency end. These special applications are
implemented in the form of suitable server and/or backend components.
252. For more details on the structure and layout of OSCI transport, refer to the extensive documentation available at: http://www.osci.de/
253. Refer to "Contact partner – competence centre" on page 133
page 135
These asynchronous forms of communication always take place via mailboxes and require
that the recipient itself actively collects messages from a mailbox of an intermediary. The
VPS also enables secure synchronous communication. In this case, messages are not sent
via a mailbox, but instead directly to a recipient who for this purpose must "listen into" a
defined connection and receive messages.
In concrete terms, there are five different application scenarios which differ significantly
with a view to their suitability for certain application cases. These scenarios cover all forms
of communication required in eGovernment. The sequence in which the scenarios are presented below shows them as becoming increasingly complex and more integrated rather
than isolated.
Communication via e-mail
Public agencies and external communication partners exchange encrypted and/or signed
e-mails (SMTP). The agency can use the VPS mail application to decrypt and check the signature of incoming e-mails.
Outbound e-mails can also be (centrally) encrypted and also signed using the VPS mail
application based on a set of rules. "Mixed forms" of processing (e.g. local signature – central encryption, recryption) are possible, refer to Figure A-4.
Citizen /
business
Public agency / officer
Centrally, if
necessary
VPS mail gateway
E-mail client
e.g. MS Outlook
Plug-in for
signature and
encryption
OCSP/CRL relay
Backend mailer
e.g. MS Exchange
E-mail client
e.g. MS Outlook
VPS kernel system
Figure A-4: Scenario 1 – e-mail communication using the VPS
Advantages:
a. Basic technology (e-mail) is already in widespread use
b. Good suitability for "informal" communication (queries, notifications, ...)
c. The agency and customer do not have to be permanently online (asynchronous communication)
Restrictions and limits:
a. Few possibilities to structure incoming communication flows and to pass these on automatically to special applications (free text, misrouted documents, ...)
b. There are very few products available for the qualified signing of e-mails (written form!)
and those that are available must be installed as additional plug-ins that may have to be
purchased.
page 136
c. The legal situation is unclear with regard to opening access to citizens for replies (administrative procedure law)
d. No proof of service, this is why this is critical, for instance, in the case of communications
with a deadline.
e. The problem with spam
Communication via OSCI web mail
Using the electronic mailbox for courts and public administrations (EGVP) or any other VPS
client available, secure "web-mail" communication between the public agency and the customer is carried out via the OSCI transport mechanisms. The messages are temporarily
stored in mailboxes (encrypted) with the OSCI intermediary. Either the public agency itself
or a third party can assume the role of the intermediary. The client components with the
agency staff and with the customers are technically similar and are based on the OSCI client
enabler of the virtual post office (VPS). With the help of these components, the OSCI messages are compiled and, if necessary, the card reader for the qualified signature is triggered
(output) and/or the so-called "inner OSCI envelope" is opened (input). This is clearly presented in Figure A-5.
Citizen /
business
Intermediary
(externally, if
necessary)
Public agency /
officer
Centrally,
if necessary
EGVP client
(with OSCI
client enabler)
JAVA WebStart
OCSP/CRL relay
OSCI manager
(mailboxes)
EGVP client
(with OSCI
client enabler)
VPS kernel system
JAVA WebStart
Figure A-5: Scenario 2 – OSCI web mail communication (e.g. EGVP)
Advantages:
a. Easy-to-use (very similar to e-mail), flexible communication (free text and attachments).
b. Scaleable security mechanisms right though to the qualified signatures "on board".
c. Secure access to mailboxes using OSCI mechanisms with confirmation of receipt.
d. The agency and customer do not have to be permanently online (asynchronous communication).
e. Registration with the intermediary makes it possible to obtain the necessary consent of
the customer required pursuant to administration law.
f.
Confirmation of transmission can be obtained immediately. This improves reliability, for
instance, especially with transactions with a deadline.
g. A "routing slip" is integrated with information concerning signature check and certificate validity.
page 137
Citizen /
business
Special-application
client
Intermediary
(externally,
if necessary)
Centrally, if
necessary
OSCI
client enabler
(integrated)
JAVA WebStart
Public agency /
officer
Specialapplication
software
OSCI manager
(mailboxes)
OCSP/CRL relay
OSCI
backend enabler
(integrated)
VPS kernel
system
VPS kernel
system
Figure A-6: Scenario 3 - OSCI-based communication via a web-based special application
a. Registration with the intermediary is required in advance.
b. In the "standard configuration", no automated passing on in special applications, messages must be manually sent and collected ("active recipient").
c. The EGVP client must be previously installed via JAVA Web Start.
OSCI communication with automated communication with special applications
A web-based special application which already exists or which is to be developed (e.g. a
form server) uses the mechanisms of OSCI transport to secure communication with the customer. For this purpose, the special application client used by the customer uses the OSCI
client enabler. At the server end, the OSCI mechanisms are integrated via the OSCI backend
enabler using an adapter specific to the special application, refer to Figure A-6.
Advantages:
a. Synchronous scenarios and passive recipients can also be implemented.
b. Automated import into special applications is possible.
c. Particularly suitable if an existing special application is to be secured by OSCI.
a. Registration with the intermediary is required in advance.
b. The development work required for manufacturing client components and the integration of the special application.
Communication via client-server special applications without the use of OSCI
A special application that already exists or is to be developed and which handles communication without using OSCI transport, uses signatures and authentication methods of the
virtual post office components for encryption. Depending on how the special application is
designed, the interface of the VPS core system, the so-called Document Interface (DI), can
be directly addressed, and the authentication and verification components of the virtual
post office (VPS) can be used, refer to Figure A-7.
Advantages:
a. No VPS or OSCI specific restrictions for the special application, however,
page 138
Citizen /
business
Centrally, if
necessary
Specific
clients
Authentication
client
VPS kernel system
Verification
client
Authentication
module
JAVA WebStart
Verification
module
OCSP/CRL relay
Special-applicationspecific
software components
(backend systems)
Figure A-7: Scenario 4 - Client-server special application with the use of OSCI
b. Use of cryptographic functions of the virtual post office in the special application (uniform cryptography); including the connection of trust centre directory services.
"Normal" development work required for integrating the VPS interfaces (the specific advantages of using OSCI components no longer apply).
A particularly special case with this scenario is the use of the VPS authentication module
which not only performs certificate-based authentication but also enables application or
agency-specific authentication processes. Furthermore, the functions of the verification
modules can, however, also be used in order to verify signatures.
Use of the virtual post office (VPS) by backend systems
An agency-internal special application (e.g. archiving system, single-sign-on system, workflow, ...) uses the services of the VPS as a "cryptography server", for instance, to obtain time
stamps, to verify certificates or to encrypt documents, refer to Figure A-8.
Centrally, if
necessary
VPS kernel system
Special-applicationspecific
software components
OCSP/CRL relay
(backend systems)
Figure A-8: Scenario 5 - Use of the VPS by backend systems
page 139
A.4.4 Interfaces
A.4.4.1 Programming interfaces
The virtual post office (VPS) comes with a software development kit for OSCI communication. This API is described in the manual of the respective VPS release.
A.4.4.2 Data interfaces
The universal XML interface with the VPS core system is the Document Interface.254
The sources referred to above also contain similar interface descriptions for the authentication module and the verification components. Validation of cryptographic certificates by
the OCSP/CRL relay is triggered via an XKMSv2 interface that is also described in detail in
the interface description contained in the source referred to above. The further activation
of public key directory services from the relay are subject to the manufacturer's specifications. For this purpose, both OCSP queries and revocation lists (CRL) are supported via LDAP.
The TMS protocol is used to connect time stamp services.
A.4.5 Operation
At its current level of development, there are no plans for central (i.e. agency-spanning)
operation of the VPS. Since data can in principle also be decrypted in the VPS kernel system,
high requirements must be set also with regard to data protection.
Two VPS components are especially well suited for central operation:
a. OCSP / CRL relay: Central operation for federal agencies is currently being prepared in
detail at the time of preparing this document (June 2006).
b. OSCI intermediary: Some project-specific implementations exist here.
One key design criterion for VPS was the most far-reaching support of customary operating
platforms255 (operating systems, application servers, databases, …). It was particularly
important that at least one of the platforms supported can be completely established with
open-source components.
The VPS is being productively supported in a host of eGovernment projects by the Federal
Government. Some examples are:
a. Online emission trading by the German Emissions Trading Authority at the Federal Environmental Agency
254. A description of the Document Interface can be found at: http://www.bsi.bund.de/fachthem/vps/
publikationen.htm.
255. A detailed, continuously updated list of the platforms supported can be found at: http:// www.bsi.bund.de/
fachthem/vps/publikationen.htm.
page 140
b. Electronic legal communications by the federal courts
c. Registrations for the import and export of protected animal and plant species (CITES)
with the Federal Agency for Nature Conservation
A.4.7 Outlook
The VPS will also be expanded as needed in the years to come. User experience will also be
contributed to this process. One special focus will be the provision of client components
that can be used in a flexible manner and the opening up of new use scenarios.
For the latest information on the further development of the VPS, please go to: http://
www.virtuelle-poststelle-bund.de/.
A.5 OFA system - Form Management System (FMS)
A.5.1 Introduction
With the one-for-all system (OFA system) form management system and using the Lucom
FormsForWeb software available to public agencies, administration processes can be
handled in a media-consistent manner with eForms via the intranet and Internet. The FMS
can be used both centrally for multiple public agencies as well as decentrally for individual
online services.
Contact in matters related to develop- Mr Markus Schulmeyer
ment, operation and competence
markus.schulmeyer@zivit.de
centre
Zentrum für Informationsverarbeitung und Informationstechnik (ZIVIT)
Wilhelm-Fay-Straße 11
65936 Frankfurt am Main
Tel.: +49 1888 680-7447
Fax: +49 1888 680-7554
Homepage
https://www.formulare-bmf.de/
A.5.2.1 Overview
The form management system supports the main steps of web-based use of internal and
external forms with parallel use of paper forms. This includes the creation and publication
of eForms and forms by the public agency as well as the filling in, saving, signing, encrypting and sending of eForms by users. Furthermore, media-consistent receipt of eForms and
the provision of form data is enabled for further processing in the agencies' special applications. Paper forms and eForms are expected to be used parallel for quite some time.
page 141
The following business cases describe potential uses of the form management system in
conjunction with other OFA systems or services and the related eGovernment applications.
Changes, such as amendments and restrictions related to functional scope, may arise
during the course of ongoing further development depending on the requirements of the
federal agencies.
Electronic submission of an eForm to a public agency
a. Creation of the eForm by the public agency. Additional functionalities, such as validation of data, are possible.
b. Providing the eForm in conjunction with the public agency's online service and publication in the form centre
c. Filling in the eForm online or offline; local storage of the eForm by the user
d. Electronic signing, encrypting if necessary, and electronic mailing of the completed
eForm
e. Paper-based or digital further processing of the application by the public agency
Integrated data exchange for services using eForms
a. Creation of the eForm by the public agency. Additional functionalities, such as personalisation or validation of data, are possible.
b. Providing the eForm in conjunction with the public agency's online service and publication in the form centre; adapting the eForm to the user's specific requirements
c. Filling in the eForm online / offline at the computer; if necessary, data reconciliation
based on special applications of the online services
d. Electronic signing, encrypting, if necessary, and connection to other OFA systems and
services (such as ePayment) and mailing of the completed eForm; if necessary, adding
electronic attachments (such as proof)
e. Receipt by the virtual post office (signature check, decryption, if necessary) of the electronically signed and/or encrypted eForm and electronic transmission to the special
applications belonging to the online service
f.
Communication with the user (e.g. confirmation of receipt, reporting incorrect information) as well as status inquiry by the user
g. Possible involvement of third parties (for example, other public agencies, financial institutions, etc.) for application processing
A.5.3 Interfaces
A.5.3.1 Programming interfaces
Within the scope of the Servlet / Java server pages technology and the Struts framework
used, the developer has access to their disclosed interfaces.
page 142
A corresponding description can be found in the standard documentation for Java API for
Servlets Version: 2.3 and Java API for Java Server Pages Version: 1.2 from Sun Microsystems
as well as the Struts framework used, version 1.1.
A.5.3.2 Export interfaces
a. StreamServeServer – Generation of files in the following formats: XML, PDF, CSV (TEXT),
BMP, GIF, JPEG, PNG, TIFF, e-mail
b. Web-Service (SOAP) interface – Provision of form data in the following formats: XML,
PDF, CSV (TEXT), BMP, GIF, JPEG, PNG and TIFF
c. Virtual post office – Provision of form data in the following formats: XML, PDF, CSV
(TEXT), BMP, GIF, JPEG, PNG and TIFF
d. Connection of databases using JDBC drivers
A.5.3.3 Import interfaces
a. Web-Service (SOAP) interface
b. XML
c. LDAP
d. HttpServlet for processing XML files
e. Connection of a database using a JDBC driver
f.
Paper forms (scan and run module)
A.5.4 Operation
Note: The form server can be used both on the Internet and on the intranet. The information supplied here applies especially to use on the Internet.
Central operation of the FMS for public agencies is offered by ZIVIT. In this case, the entire
infrastructure, including three-zone architecture, is made available to the agencies according to the BSI's framework security concept.
The form management system can be operated in a platform-independent manner within
an application server, integrated into existing applications, or exclusively. Operation with
open-source products is possible.
a. Assigning German value-added tax identification numbers256
b. Internet shipping registration257
c. Agricultural diesel refunds258
256. Refer to http://www.formulare-bmf.de/
257. Refer to https://www.versand.internetzollanmeldung.de/
page 143
A.5.6 Outlook
a. Documentation of the potential for integration offered by the FMS (Portal, DOMEA, EAI,
VPS, SAP)
b. Integration of an OCR scan option (scan and run)
c. Automated invoice receipt recognition
A.6 OFA system – Content Management System (CMS)
A.6.1 Introduction
The one-for-all (OFA) Content Management System is designed to standardise and facilitate information management and updating in the intranet and Internet environments of
federal authorities.
This system which is also known as the "Government Site Builder" brand is a comprehensive solution which was specifically developed to meet the needs of the federal administration. It features client capability, enables the implementation of the requirements for "barrier-free" Internet according to the barrier-free information technology ordinance (BITV),
and offers a configurable layout which is orientated towards the design guidelines published by the Press and Information Office of the Federal Government ("Internet Styleguide of
the Federal Government"). The system comes with pre-configured modules which public
agencies can accept as their own standard solutions or which they can adapt to their specific needs. The OFA system supports the production process with a roles and privileges concept as well as workflows with related quality assurance mechanisms. The content management framework from CoreMedia AG serves as the technological platform.
The economically efficient use of a powerful content management system by the federal
administration is possible thanks to central development and joint use of upgrades.
The solution is available both as a central platform system at the Federal Office for Information Technology (BIT) and as a distributed system under the responsibility of the respective
public agency.
258. Refer to http://www.formulare-bfinv.de/
page 144
Contact partner for matters related to Mr Michael Kalkan
development and operation
michael.kalkan@bva.bund.de
Bundesstelle für Informationstechnik (BIT) im
Bundesverwaltungsamt
Postal address:
50728 Köln
Office address:
Barbarastr. 1
50735 Köln
Tel.: +49 1888 358-36 96
Fax: +49 1888 358-71 36 93
Contact partner – competence centre Mr Stefan Brombach
stefan.brombach@bva.bund.de
Bundesstelle für Informationstechnik (BIT) im
Postanschrift:
50728 Köln
Hausanschrift:
Barbarastr. 1
50735 Köln
Tel.: +49 1888 358-1641
Fax: +49 1888 358-3899
Homepage
http://www.government-site-builder.de/
A.6.2.1 Overview
The CMS OFA system is based on the content management system from CoreMedia AG. It
constitutes a powerful "Enterprise Content Management System" (ECMS) which, for
instance, enables the operation and administration of online activities for several agencies
on one system (client capability).
The CMS is accessed via editors. An editor based on Java technology and a browser-based
web editor are available. So-called preview-based editing permits direct editing of documents from within the website preview.
The use of the CMS OFA system enables the separation of design, contents and logic. Contents are provided and administered in a structured manner separate from the layout. This
is carried out on the basis of so-called document types which are used to classify and provide the contents. This means that after just a short period of training, editorial staff can
page 145
focus on their core task, i.e. creating contents, without having to acquire special technical
skills.
Within the CMS, contents are structured on the basis of these document types and their
mutual relations. A document type includes attributes (properties) which contain the real
information. Relations describe the relationships between the document types and determine which documents can contain lower-level documents and which attributes they inherit from them.
The OFA system offers several document types which can be edited or amended as
required, e.g. press release, speech, picture, job vacancy, and interview. However, the CMS
OFA system also enables the administration of graphics and download files as distinct
document types.
Uniform and standardised document types also contribute towards easier exchange.
Media-neutral output and rendering of the contents provided in this manner are ensured
by presentation templates which consider the Federal Government's Internet Styleguide.
A version management function within the CMS supports the administration of documents
and enables access to the latest or earlier versions of a document. On the basis of the version selected, a new version is generated when a document is edited. The previous version
of the contents is saved accordingly. The version management functionality of the CMS
OFA system ensures that access by other authorised users to a document that is currently
being edited is restricted to read access only. After editing, the document, including the
changes carried out in it, is returned to the system where it is once again made available to
other users for editing. The link management feature of the OFA system ensures the checking and correct resolution of internal links and supports this function in the case of external links.
Further technical functionalities are enumerated below.
a. Support of multilingual capability and internationalisation
b. Provision of possibilities for multi-site and multi-channel publishing
c. Workflows, including a notification system, in order to represent editorial processes (4eyes and 6-eyes workflows, proxy procedures, possibility of adding client-specific workflows)
d. Authorisation system (roles, privileges)
e. Search functions
f.
CSS-style definitions
g. Creation of HTML forms
h. Newsletter mailing
i.
Various additional functions, such as RSS newfeeds, guestbook and shopping cart
The OFA system is supplied along with a completely prepared website as an out-of-the-box
solution (GSB SL – standard solution) that can be easily adapted by users to meet a specific
demand.
page 146
Two business cases were identified for the CMS OFA system. The description and classification of business cases serve as a basis for decisions concerning the use of the OFA system.
Information website
Different kinds of contents must be administered and presented in the case of pure information services, such as public agency websites or Internet offers focusing on specific subjects. Change frequency and document numbers are usually high enough to justify the use
of a content management system.
Public-agency website with access to special applications
Special applications of a communication or transaction nature must often be presented
and/or integrated within the framework of websites. The bundling of different special
applications and their uniform presentation, in particular, call for the use of a CMS solution.
The CMS acts as an integration platform in cases like this.
This integration is achieved by communication between the CMS (as the integration component) and the special application (application interface) on the middle tier level, with the
possibility to export contents from the special application on the basis of XML files to the
CMS. Furthermore, the presentation tier can be used – irrespective of the real CMS – to
retrieve and visualise contents directly from the application interface of the special application. Possible communication protocols include SOAP, CORBA, RMI as well as direct interprocess communications.
Furthermore, the editing system of the CMS can be used to integrate additional contents –
such as help texts and background material – and to link these to the contents of the special application on the presentation tier. The web front-end of the special applications is
implemented by the CMS OFA system.
Figure A-9 shows five different special applications. Three of these special applications
exchange contents with the CMS via different communication channels (e.g. API, SOAP or
RMI). The data exchange format and the communication interfaces can be implemented on
the basis of the interfaces259 provided by the CMS.
The other two special applications are integrated in different ways into the website irrespective of the CMS on the presentation tier (for example, using a special API or a servlet).
Communication via API or servlet means direct access to programming interfaces within
the same runtime environment. In the case of communication via SOAP or RMI, the OFA
system and the special applications may be distributed to different computers in the network.
259. Refer to section A.6.3 "Interfaces" on page 148
page 147
Public-agency website
with access to five
applications
Client
Web browser
Presentation
Servlet
API
Middle layer
Middle layer
Middle layer
Application
interface
Application
interface
OFA system CMS
Application B
Application A
API
RMI
SOAP
Middle layer
Middle layer
Application
interface
Application
interface
Application
interface
Application C
Application D
Application E
Middle layer
Figure A-9: CMS-based special aplications integrated into a public agency website
A.6.3 Interfaces
Up-to-date contents are a crucial factor for the success of a website. However, this information often stems from different systems or external partners. Furthermore, part of the contents must sometimes be disseminated to several partners. Moreover, existing contents of
legacy systems are often to be reused in many intranet and Internet solutions and, when
required, presented within the framework of the newly designed website. This will usually
require further amendments or additional attributes for this legacy data.
The content management system from CoreMedia as the underlying system of the OFA system hence includes interfaces for both XML import and XML export. However, since every
system uses another XML specification, it is not possible to directly import this data into the
target system. This is why special XML importers260 are additionally offered, such as:
a. AP-Import (IPTC 7901)
b. dpa-Import (IPTC 7901)
c. dpa Newsfeed Interface
Interfaces with more far-reaching functionality can be implemented, for instance, in an
event-driven manner on the basis of SOAP as web services in a Java platform-compliant
software architecture. If additional interfaces and XML importers are needed, these can be
developed in the projects and made available to the federal authorities.
260. The "special" XML importers listed here are not included in the license agreement between the Federal Government and CoreMedia.
page 148
A.6.4 Operation
For public agency websites based on Government Site Builder (GSB), the Federal Office for
Information Technology (BIT) offers hosting as an ASP service261. Operation takes place in
the high-availability computer centre of the Federal Office of Administration. The platform
is ideally configured to meet the requirements of GSB:
a. 24/7 availability:
b. Powerful Sun server technology
c. Oracle databases
d. Connection to the IVBB or IVBV public-agency networks
e. Automated monitoring and alarms with a central information system
f.
High security standards: DMZ, separate fire sections as well as firewall and virus protection systems – configured and tested with the German Federal Office for Information
Security (BSI)
g. A service desk via a central telephone number and e-mail address with standby service
outside office hours
Government-Site-Builder is approved for the following platforms
ment of the server):
262
(operating environ-
a. Operating systems: Solaris, Linux (SUSE)
b. Database: Oracle
The following Internet sites were implemented using the OFA Content Management System:
a. Federal Government263
b. Federal Ministry of Finance264
c. German Office for Foreign Trade265
d. Federal Office for Migration and Refugees266
e. Robert Koch Institute267
Other reference projects can be found at: http://www.government-site-builder.de/.
261. ASP = Application Service Providing
262. Other operating systems / databases can be used within the scope of project solutions.
263. Refer to http://www.bundesregierung.de/
264. Refer to http://www.bundesfinanzministerium.de/
265. Refer to http://www.bfai.de/
266. Refer to http://www.bamf.de/
267. Refer to http://www.rki.de/
page 149
A.6.6 Outlook
Version 3 of the GSB has been available since 2006. Other follow-up versions will be delivered.
A.7 OFA system bund.de portal
A.7.1 Introduction
The one-for-all (OFA) "bund.de – Verwaltung Online" portal is the central point of access to
the federal administration's electronic services and information offerings on the Internet.
Under the motto "One portal – many public agencies – all contents", public agencies and
Federal Government institutes are obliged to provide their agency data ("agency fact
sheet") on the bund.de portal, to link their eGovernment services to the portal and to publish on the portal all forms, suitable job vacancies, invitations to tender and sales. Data cooperation with several federal institutions and federal states has been established so that
data concerning job vacancies and calls for tender can be automatically imported into
bund.de. Bund.de is actively involved in the eGovernment portals of the federal states,
municipalities and the Federal Government268 and is also participating in the Editorial
Board of the EU's "Europe for You"269 partner portal.
Figure A-10: Start page of the bund.de portal
268. http://www.deutschland-online.de/Vorhaben/vorhaben2.htm
269. http://ec.europa.eu/youreurope/index_de.html
page 150
A distributed Content Management System already provides access to around 1,900 local
editors enabling them to publish and update via a web interface public agency information
either independently or when necessary with the support of the central portal editorial
office of the Federal Office of Administration (BVA).
The portal lists all Internet offers and services, addresses and other information concerning
the structure of the federal agencies. This information is listed separately for the target
groups: "Citizens", "Business and Science" and "Administration and Institutions". The eGovernment offers by Federal Government, federal states, municipalities and the EU on the
Internet can be accessed via this portal. With more than three million hits and more than
400,000 visitors a month, bund.de is one of the Federal Government's most important portals.
Contact partner for matters related to Mr Peter Wiethoff
development
peter.wiethoff@bva.bund.de
Bundesverwaltungsamt – BIT 3
Barbarastr. 1
50735 Köln
Tel.: +49 1888 358-1636
Fax: +49 1888 358-3899
Contact partner – editorial management
Mr Camillo Garzen
redaktion-portal@bva.bund.de
Bundesverwaltungsamt – Ref. VIII 7
Barbarastr. 1
50735 Köln
Tel.: +49 1888 358-3300
Fax: +49 1888 358-3899
Homepage
http://www.bund.de/
FAQ / Documentation / Guided Tour
Help pages, FAQ system and guided tour for target groups can be reached via the service navigation
A.7.2.1 Overview
The bund.de portal is technically based on the OFA system CMS (Government Site Builder,
version 1.2) from the BundOnline Initiative and the search engine software (ESP 4.x270)
from FAST. Bund.de data is updated and maintained by local editors at distributed locations and by a central portal editing office at the Federal Office of Administration. The
respective public agency always has editorial control of the information to be presented.
270. Enterprise Search Platform
page 151
The portal is implemented in several stages, with the third of three development stages
currently underway.
Stage 1
Since the CeBIT in March 2001, the "search" and "find" core functions have been available at
the first stage. The portal hence appears to Internet users in the familiar form of a catalogue
with a search engine.
The catalogue helps to retrieve information offerings and services in the form of annotated
links which are divided into subjects. The public agency database is updated in a de-centralised manner and covers the supreme constitutional organs, all the federal authorities and
major institutional recipients of funds, e.g. large libraries, museums and research institutes.
The federal states are represented with their constitutional organs, the supreme administrative levels and further public agencies, whilst the municipal level is represented with the
central organizations and the large cities.
The central full-text search function is based on a search index which covers the complete
offerings from all public agencies. The geo-search function shows users maps with the locations of public agencies. Several columns of the portal offer users the possibility to register
for e-mail subscriptions. Any information that is newly published via the portal editing system is immediately circulated by e-mail.
Users can send inquiries to public agencies via a contact form, by e-mail, fax or telephone.
The portal editing team answers the inquiries or passes them on to the appropriate public
agencies for further action.
Stage 2
The focal task of the second stage was the implementation of the ordinance on the creation
of barrier-free information technology (BITV) which came into effect on 24 July 2002. At the
CeBIT in March 2003, the federal administration's "bund.de" portal went online in a barrierfree condition.
Besides the revision of the portal in line with the ordinance on the creation of barrier-free
information technology, the number of central services on offer was increased. In 2002, the
most important forms of the federal administration, for example, were made available via
the new online form centre of the portal. Job centre, sales and invitations to tender were
upgraded by adding new functions. The municipality search function now offers a full
range of important municipal data in an interactive format.
Stage 3
In the third stage in September 2004, the portal was migrated to the OFA system CMS
(Government Site Builder, version 1.2) of the BundOnline Initiative, thus creating the foundation for further development of bund.de both in terms of design and technology.
Since its successful relaunch in May 2005, the portal offers dedicated content areas for
three target groups: "Citizens", "Business and Science" and "Administration & Institutions".
page 152
This new structure – combined with a new design, an improved navigation structure and
new functions – all go into making the portal even more user friendly.
All the Federal Government's public, electronic services, which were implemented within
the scope of the BundOnline Initiative, are fully implemented on the Federal Government's
service portal and can be researched there.
The federal agencies are obliged to link and/or publish public-agency data ("public agency
fact sheet"), eGovernment services, forms as well as suitable job vacancies, invitations to
tender and sales on the bund.de portal271. This is enabled by automated interfaces and a
network of trained editors in the federal agencies.
The bund.de portal provides the Federal Government and public administrations with a
joint online platform where they can widely disseminate their services, special information
and contact data. The business cases discussed below can serve as an orientation aid for
decisions concerning the use of the portal and of its functions.
Maintenance and updating of the Federal Government's master database (name of the public
agency, abbreviation, addresses, web and e-mail addresses, locations, tasks, business field) as
well as the Federal Government's address and abbreviations directory.
a. The master and directory data of public agencies to be published is created.
b. The portal editing system is used to publish this information on the portal.
The parallel provision of public agency addresses on the portal and in the directory service
of the Berlin-Bonn Information Network (IVBB) has been replaced and this data is now provided per e-mail and used to update the IVBB directory.
Maintenance and updating of public-agency online services
a. The service information to be published is compiled.
Maintenance and updating of the central information services (forms, job vacancies, invitations
to tender and sales)
a. The offers to be published are compiled.
b. The data is imported into the portal via the portal editing system or by standardised
data import from collection points.
Maintenance and updating of current information
a. Current information is made available for publishing or is created by the editorial unit.
271. Cabinet decision in 03/2005
page 153
Maintenance and updating of municipal data and the geographic locating of addresses
a. Information about cities, districts and municipalities is provided along with geographic
locating information.
b. A routine of the portal editing system is used to publish this information on the portal.
A.7.3 Interfaces
The existing interfaces are based on the import and export possibilities offered by the OFA
system CMS (Government Site Builder, version 1.2) or were implemented as a project solution.
XML import interfaces are currently available for automatic import of job vacancies and
invitations to tender into bund.de.
If additional interfaces and XML importers are required, these can be developed and made
available. Other interfaces can be implemented in an event-driven manner on the basis of
SOAP as web services in a Java platform-compliant software architecture.
A.7.3.1 Web Services
Geographic locating of an address sent is provided to a restricted user group as a web service.
Electronic invitations to tender are imported into the eTendering platform via a web service.
A web service was set up for data co-operation with the federal states and for maintaining
and updating their master and organizational data; the first partner is the federal state of
Brandenburg.
Data export
The editing system includes intervention options for data export operations which the portal editor can use to export data records. The export functionalities include the following
options.
a. The portal editors can export the Federal Government's address directory as an XML or
CSV file.
b. The complete address directory can be downloaded (exported) from bund.de as a PDF
file.
X.500 export
Addresses of public agencies are made available in CSV format to the directory service of
the Berlin-Bonn Information Network for import via its X.500 interface.
page 154
A.7.3.3 Import Interfaces
Master data
Public-agency master data can be imported via an XML format for public-agency entries
and addresses, refer to section A.7.3.1 "Web Services" on page 154.
Vacancies
An import service for publishing public service job vacancies which is currently used by the
following content partners:
a. Federal Employment Agency via a proprietary CSV format (including vacancies for training)
b. Federal Waterway and Shipping Administration in XML format
The task of winning other content partners is already underway.
Invitations to tender
An import service for publishing invitations to tender by the Federal Government and the
federal states which is currently used by the following content partners:
a. Federal Waterway and Shipping Administration in XML format
b. Hessian Invitations to Tender Database in XML format
c. Invitations to tender by the federal state of Saxony in XML format
d. North-Rhine Westphalia Tendering Marketplace in XML format
The task of winning other content partners is already underway.
Sales by the Federal Government (real property)
Concept development for an import service for publishing property for sale by the Federal
Government is already underway with the Federal Agency for Property Tasks as a content
partner.
A.7.4 Outlook
Bund.de is available to data co-operation partners so that content can be imported. Within
the scope of this data co-operation, new content partners are being continuously won for
bund.de and integrated. Furthermore, automated import interfaces are being created in
order to guarantee media-consistent data import for selected areas of bund.de.
Plans also exist to expand bund.de to include the latest versions of the software components used and to expand the target-group topic pages on the bund.de portal. Usability
optimisation is seen as a process and hence forms a permanent part of enhancing the
bund.de portal.
page 155
A.8 OFA system - GeoPortal.Bund
A.8.1 Introduction
The services offered by the OFA system GeoPortal.Bund include searching public, general
geo-data of the Federal Government and the federal states along with the visualisation of
this data in the form of browser-based maps (web mapping) on the Internet and on the
public-agency network (TESTA, IVBV / IVBB). GeoPortal.Bund operates as an internet-based
broker which includes distributed services by agencies and public institutions on the basis
of national and international standards.
Contact partner for matters related to Dr. Olaf Heimbuerger
development
olaf.heimbuerger@bkg.bund.de
Richard-Strauss-Allee 11
Tel.: +49 69 6333-319
Fax: +49 69 6333-441
Contact in matters related to operations and competence centre
Mr Jürgen Walther
juergen.walther@bkg.bund.de
Richard-Strauss-Allee 11
Tel.: +49 69 6333-297
Fax: +49 69 6333-446
Homepage
http://www.geoportal.bund.de/
A.8.2.1 Overview
The GeoPortal.Bund system generally provides a platform for the electronic publication of
basic geo-data and special geo-data from public institutions.
The processing of the data entered into GeoPortal.Bund primarily involves publishing and
compiling maps from various public institutions (e.g. the Federal Centre for Cartography
and Geodesy, the Federal Agency for Nature Conservation, the Federal Statistics Office,
etc.). The compilation is sent to the web browser as a finished product in the form of a thematic map with multiple layers as a PNG file (grid image). The geo-data catalogue integrated into GeoPortal.Bund also enables the targeted search for geo-data in distributed systems.
www.geoportal.bund.de offers an application and/or publication platform for geo-data
that complies with the requirements of the "Ordinance on the creation of barrier-free information technology pursuant to the law on equal opportunities for the disabled)" (BITV), of
page 156
the W3C, SAGA and Federal Government's styleguide. The entire GeoPortal.Bund application is free from active content (e.g. Javascript).
GeoPortal.Bund features an intuitive user interface which leads from research (geo-data
catalogue) to detailed information on the geo-data and directly to the visualisation of the
geo-data (basis viewer) and vice versa. The integration of additional, user-defined map services is conveniently designed with a three-stage user dialogue that detects errors in distributed services. The map services registered in the database undergo automated monitoring which triggers escalation mechanisms when an error is detected.
Providers of map services (WMS, WFS272) and catalogue services (CSW273) can register or
have registered their services on GeoPortal.Bund. The portal can provide access to all the
services named, both freely and with access protection for defined user groups.
Geo-data catalogue
The publication of metadata on the GeoPortal.Bund web interface is enabled by entering a
catalogue service in a configuration file, refer to section A.8.3.2 "Import interfaces".
If a GeoPortal.Bund user triggers a search in the geo-data catalogue with a keyword, the
portal refers to the catalogue services entered in the configuration file and the meta-information systems behind this. The hits from the various catalogue services reported GeoPortal.Bund are then compiled by GeoPortal.Bund and returned to the user in the form of hit
lists. The hit lists contain descriptions of the geo-data records found, e.g. title, summary,
time of capture, data format and responsibility for distribution.
The advantage for publishing public agencies is that they can use the presentation interface (query masks, tables) of GeoPortal.Bund. Public agencies are often obliged to provide
electronic information on their data offer (including the environmental information law), so
that using the presentation interface of GeoPortal.Bund means enormous benefits for the
public agencies / institutions connected. The advantage for the user is that queries can be
submitted using standardised interfaces of different, distributed information systems.
Visualising topographic and thematic maps
Publication takes place on the GeoPortal.Bund web interface by entering a map service in a
database or a configuration file, respectively. It is possible that the GeoPortal.Bund administrator integrates this service or that the data provider calls via the Internet a corresponding
administration service on the GeoPortal.Bund interface and independently registers his service himself.
The contents of the map service are published the GeoPortal.Bund map viewers. The map
viewers are presented on the user interface274 as a basic version without active contents
and with an expert viewer (Java applet) with enhanced functionality. With both viewers it is
274. Refer to http://www.geoportal.bund.de/
page 157
possible to integrate other interfaces (map services), to zoom in and out, to move a map
section, reset to the original section, navigate between views, query attributes, save and
print views and compilations, transform co-ordinates, search for places, as well as to display
a 3D view of the current map section.
It is also possible for the user to visualise any particular map compilation and to change the
sequence of its presentation. For instance, geo-services by the nature protection administration (protected areas) can be overlaid and displayed in 3D with land-use data and soil
information in order to be able to estimate, for instance, fertiliser and pesticide uptake in a
protected area following rain events. The application cases can be expanded as required.
Distances and surface areas can be additionally measured in the expert viewer. User
guidance is somewhat more comfortable here.
Individually compiled map compilations can be called in other GIS systems and further processed using a standardised configuration file (WMC file, Web Map Context Document).
The advantage for the publishing agency is that it can use the presentation interface (basic,
expert viewer) of GeoPortal.Bund. The advantage for the user is that he/she can combine
geo-data or maps, respectively, from different specialist sources.
Use of geo-services in eGovernment applications
GeoPortal.Bund also enables users to compile as required catalogue and map services by
specialist data providers and to then make these available to third parties in a standardcompliant manner as automated services, refer to section A.8.3.1 "Export interfaces". For
instance, topographic maps can be combined via GeoPortal.Bund with the location in
nature conservation areas so that they can be used as background maps in special
applications.
A.8.3 Interfaces
GeoPortal.Bund offers the possibility to cascade map services and catalogue services by
public institutions and public agencies and to then make these available in an OGC/ISOcompliant manner as automated web services, refer to section A.8.3.2 "Import interfaces".
A.8.3.2 Import interfaces
An OGC-compliant CSW service is required as an interface for importing metadata into GeoPortal.Bund. The portal imports the data via OGC-compliant WMS and WFS services in order
to visualise any particular, division-independent maps.
GeoPortal.Bund supports the current versions of the OGC specification275.
page 158
A.8.4 Operation
The brokers (catalogues services and map services) as well as the geo-data catalogue and
the map viewers are centrally provided for publishing any division-spanning geo-data and
hence offer considerable potential for synergy.
The respective service (CSW, WMS, WFS) must be installed in order to transmit the necessary information to GeoPortal.Bund.
The portal provider supports the operation of a distributed OGC-compliant CSW for integration in the portal by supplying free software. If necessary, the competence centre can
provide support for installing the software.
Within the scope of a pan-European test of the interoperability of existing catalogue services on the basis of the current OGC recommendation, GeoPortal.Bund was the only system in 2006 to fully meet with the requirements. The test was conducted by the European
Commission's Joint Research Centre (JRC) in Ispra.
"Pegel-Online" was integrated as a special application into GeoPortal.Bund. Pegel-Online is
used to access the water level measurement stations of the Federal Waterway and Shipping
Administration (WSV) in realtime and to present the course or development of water levels
on overview maps. All water level presentations are interactive, i.e. each symbol can be
individually clicked in order to access additional information about the water level (co-ordinates, fluctuations, etc.). This provides the user with the latest information, e.g. in flooding
situations, from different sources (WSV, BKG).
A.8.6 Outlook
The GeoPortal.Bund OFA system is available for productive use. The pertinent competence
centre ensures maintenance, service and operation. The connection of other services is
continuously being carried out. For the latest information, please go to: http://www.geoportal.bund.de/.
In future, the map viewers are to provide more far-reaching functions with regard to data
analysis.
The further development of standards means that it is necessary with the geo-data catalogue to make some adaptations in the broker and in the interface in early 2007. In the long
run, the search results will be improved even more by using thesauri.
page 159
A.9 Infrastructure - Federal Administration Information Network (IVBV)
A.9.1 Introduction
A communication platform based on the Internet Protocol (IP) is made available to institutions and Federal Government agencies.
The Federal Administration Information Network (IVBV) is a further development of the Berlin-Bonn Information Network (IVBB) which disseminates information and communication
services on a nation-wide level, integrates the entire federal administration as users and
considers public agency demand for long-distance communications.
Contact for matters related to organi- Mr Jürgen Blum
zation
IT2@bmi.bund.de
Bundesministerium des Innern
Alt-Moabit 101 D
10559 Berlin
Tel.: +49 1888 681-4260
Fax: +49-1888-681-54260
Contact for matters related to operation
Service Center des IVBV
sc.ivbv@dwd.de
c/o Deutscher Wetterdienst
Tel.: +49 69 8062-2333
Fax: +49 68 8062-3582
Homepage
http://www.kbst.bund.de/saga-ivbv
FAQ / Documentation
http://www.ivbv.net/
A.9.2 Structure
The IVBV (Federal Administration Information Network) consists of three levels, the IVBV
network infrastructure, IVBV services and the IVBV intranet.
In the federal administration, the IVBV is to bring together the providers of information services. It offers its users the Federal Government's information services in the form of IVBV
services, for instance, from sources, such as the IVBB (Berlin-Bonn Information Network) or
BundOnline 2005.
The basis for the IVBV and the joint technical integration platform are the services and products which can be accessed under the "General Agreement for the Procurement of Data
Networks for the Federal Administration" (General Agreement on the Federal Administration Network). The federal administration's data networks (including the IVBB), along with
those agencies which up to now had no access to other networks, are joining this joint network platform, the Federal Administration Network (BVN).
page 160
This platform employs encryption devices approved by the German Federal Office for Information Security (BSI) in order to ensure that the IVBV intranet is a secure medium for the
exchange of information and IT services among the federal administration institutions connected to it, refer to Figure A-11.
Furthermore, the services defined by the general agreement enable federal administration
authorities without network access of their own to implement their own long-distance networks for communication between distributed sites using demand-based, dimensionable
network connections. Another fundamental part of the general agreement is access to the
Internet with firewall protection. Public agencies can individually request this service under
the general agreement in addition to their network connections.
Joint use of the same technical platform by public agencies and the IVBV means that it is
easy for an agency to communicate with the IVBV simply by using the network connection.
Access to the IVBV either via a public agency's network access or via an existing administration network is enabled by adding a line encryption device – the SINA box. This SINA box
ensures the confidentiality and integrity of the information transmitted via the IVBV intranet.
Internet
Network segments
(closed networks)
in the BVN
Other publicagency network
Network termination
Communication
network
NKZ
SINA boxes
NKZ
§
Bx
§
Lx
Network competence centre of
the German Meteorological Service
Public agency
§
§
§
Ln
Ln
L1
Real property of a
network of public
agencies
§
Bn
IVBV intranet
§
§
L1
B1
BVN
IVBV network infrastructure
Figure A-11: IVBV network infrastructure and Intranet
page 161
The IVBV intranet is hence formed as a closed, secured IP network across all the administration networks and authorities connected to the IVBV network infrastructure.
A "Service Center IVBV" (SC IVBV) was set up in order to monitor network operations and to
represent the interests of public authorities in relation to the network operator. In addition
to this, this centre is also responsible for managing the line encryption devices and other
central operating tasks in the IVBV.
DNS and an e-mail relay are services that are centrally provided by the SC IVBV. These services support communications between IVBV users as well as between IVBV users and users
of connected networks, such as the Berlin-Bonn Information Network (IVBB). Internet
access is implemented in the existing networks of the federal administration (e.g. IVBB) or
from case to case by the public agencies (e.g. under the general agreement on the BVN).
A.9.3.1 Technical specification of services
The services and products of the general agreement on the BVN define a non-public communication network based on MPLS technology276.
MPLS technology enables the logic separation of connections in sub-networks, i.e. the network segments. The public agencies (users) define a network segment between the connections of their sites which is isolated from other public agencies and in which unrestricted communication can take place. Transitions between the isolated network segments are
separately agreed to between users and implemented by the service provider. The IVBV
defines its own network segment with the federal administration networks and public
agencies connected to the BVN. The relevant user requests the services needed directly
from the service provider.
The basic services of the SC IVBV and the IVBB information services in the IVBV are centrally
made available to the IVBV users. Furthermore, individual services of the SC IVBV can be
agreed to in the form of individual consultancy and operative services for BVN users which
are directly settled with the SC IVBV.
Technical parameters of the Federal Administration Network (BVN):
a. Connection to the BVN via network terminal devices with an Ethernet port for access to
the BVN, as well as another optional Ethernet port for transparent access to the Internet
b. Connection bandwidths of 128 kbps to 3x155 mbps in three service variants (including,
for example, a high-availability connection with two-way routing) and further optional
parameters (including, for example, four "quality of service" classes)
c. Transparent, individual Internet access with connection bandwidths of 128 kbps to 155
mbps in three service variants
d. Secured, central Internet access as an optional service
e. Access to the BVN via dial-up and mobile telephone networks (GSM, UMTS) with userrelated billing and authentication of mobile users
276. MPLS: Multi Protocol Label Switching
page 162
The basic services rendered by the SC IVBV are as follows:
a. Monitoring the rendering of services by the service provider
b. Reporting on the services performed to BVN users
c. Co-ordination with operators of other public-agency and administration networks
d. Management (personalisation and administration) of the encryption devices (SINA
boxes) for access to the IVBV intranet
e. Operation of central services and systems of the IVBV (DNS, e-mail relay)
f.
Exchange of e-mails between IVBB and IVBV users via secure infrastructures
Information services made available in the IVBV:
a. Central services of the IVBB, e.g. directory and administration PKI
b. Database applications, e.g. EU document server, Central Aliens' Register (AZR), Legal
Information System for the Public Administration (JURIS)
c. Web offers in the IVBB for the federal administration provided in an extranet area of the
IVBB for the IVBV
d. Offers by the BIT (Content Management System GSB, TMS travel portal, etc.) and ZIVIT
(federal budgeting and accountancy service, etc.) service centres
Every IVBV user can also offer information services in the IBVB.
The Federal Administration Information Network (IVBV) is the network of providers of information and communication services of the federal administration, and is hence without an
alternative as an intranet.
Two business cases are of special interest in this context.
Access to information offered by the IVBB
Public agencies – which do not belong to the supreme federal authorities and which are
hence not IVBB users – wish to access services and information which the IVBB offers to the
federal administration.
Access is only possible if the required protection measures – for example, use of a line
encryption device as a means of securing communication – are taken and if the IVBB service
was made available on the IVBB extranet with the appropriate access rights. The user
requesting the service then connects to the IVBV. The service is made available on the IVBB
extranet by way of logic isolation of the server in question via a link with the IVBB extranet.
This service is free of charge for the service provider.
Providing information services for the federal administration in a secure environment (G2G)
When using information services, a public agency is part of a process chain. The agency
itself uses central services and systems in order to provide other public agencies with
access to its processes. As a provider of information and services, it requires a secure environment of communication and information services for its own operational purposes.
page 163
To this effect, the BVN offers the public agency high-availability access to the IVBV. The IVBV
enables secure communication with other partners within the federal administration.
The public agency as an IVBV user makes its information available to other public agencies
in the IVBV by providing an information server at the IVBV user connection and enabling
the name of the information server in the central DNS of the IVBV.
A.9.4 Operation
Authorised users can obtain more information about contacts, features and the shopping
cart of the BVN as well as about the services offered by the IVBV at: http://www.ivbv.net/.
A.9.5 Users and conditions of access
The users of the Federal Administration Information Network are chiefly members of the
legal entity "Federal Government" with facilities throughout Germany. Either the Federal
Administration Network or the Berlin-Bonn Information Network serve as points of access.
Other networks of the federal administration will use the Federal Administration Network
in order to enable their users to access the Federal Administration Information Network in
this way. The operators of the sub-networks will continue for the time being to operate the
relevant technical connection basis of the user.
In technical terms, the Federal Administration Information Network constitutes a self-contained communication network above the level of the federal administration's IP networks
which is exclusively open to authorised users. A line encryption device – a so-called SINA
box – approved by the German Federal Office for Information Security (BSI) is required at
the user end (location of a public agency) as a precondition for implementing the Federal
Administration Information Network. A central point of access to the Federal Administration Information Network was established for users of the Berlin-Bonn Information Network
who are connected to the IP backbone.
A.9.6 Connected users
The IVBV is used by 40 public agencies from all areas of the federal administration. The
three federal administration networks of the transport, finance and labour administrations,
along with their public agencies and service centres, are also connected to the IVBV. The
IVBV is connected to the joint administration network TESTA, providing access to the data
networks of the federal states and the European Union with its participants and information offers.
A.9.7 Outlook
The technical basis BVN will continue to be developed further. In 2006, for instance, access
to UMTS was created and other connection types such as SDSL are being opened up.
The number of services available via the IVBV also continues to rise. In 2006, newly developed offers, such as the Federal Government's idea database and the intranet portal for
Federal Government employees, were added to the IVBV.
page 164
A.10 Administration Public Key Infrastructure ("V PKI")
A.10.1 Introduction
The federal administration's Public Key Infrastructure with the official name "PKI-1 administration“ (referred to in this document as the administration PKI or, in short, V-PKI) provides
federal authorities, municipal administrations and public institutions with the basic technology for certificate-based security services. This makes it possible to achieve sufficient security (integrity and confidentiality of data) and clear authenticity (identification and nonrepudiability) in communications within electronic administration and business processes.
The aim of the administration PKI is to enable electronic business transactions between
administration, business and citizens – at least on the level of IT baseline protection – as
demanded in a resolution by the Federal Government on 16 January 2002, "Security in electronic legal and business procedures with the federal administration".
Contact for matters related to organization
Referat 111
v-pki@bsi.bund.de
Postal address:
Postfach 20 03 63
53133 Bonn
Office address:
Godesberger Allee 185-189
53175 Bonn
Tel.: +49 1888 9582-0
Fax.: +49 1888 9582-405
Contact for matters related to operation
Referat 215
v-pki@bsi.bund.de
Postal address: As above
Office address:
Mainzer Str. 84
53179 Bonn
Tel.: +49 1888 9582-0
Fax.: +49 1888 9582-405
Homepage
http://www.bsi.bund.de/fachthem/verwpki/
A.10.2 Structure
The administration PKI can be broken down into three areas: the policy certification authority, the certification hierarchy and the directory service. The IVBB directory service supplies
page 165
European
Bridge CA
Certification hierarchy
Directory
service
Policy certification
authority (PCA V-PKI)
Organization-spanning
connection
PCA EB-CA
Provision of
certificates & revocation
lists
certifies
CA
CA
certifies
(optionally)
sub-CA
X.500 of the
IVBB
CA
accredits
TN
TN
TN
Figure A-12: Structure of the administration PKI
the certificates and revocation lists of the policy certification authority and of the IVBB Certification Authority (IVBB-CA). Other V-PKI CAs have other directory services. The architecture is shown in Figure A-12.
As the supreme certification authority in the hierarchy, the policy certification authority
(PCA) issues a self-signed policy certificate and signs the certificates of the certification
authorities connected.
The certification authorities (CAs) certified by the policy certification authority (PCA) form
the second level of the PKI hierarchy. The users (TNs), on the other hand, are integrated via
the certification authorities assigned to them and form the lowest level of the certification
hierarchy.
Users are individuals, groups of individuals, functions and services (IT processes) who
within the scope of PKI-1 administration receive keys and certifications and who request
PKI information concerning CAs or users from the directory service. Users without a V-PKI
certificate can also request PKI information from the directory service. Pseudonyms are
accepted for individuals.
The certification authority can be operated either under the responsibility of the respective
institution or the PKI services can be rendered by commercial CA service providers.
Furthermore, each certification authority is free to choose whether or not it certifies subcertification authorities (sub-CAs). In order to warrant a practical architecture with security
guidelines suitable for checking, a PKI hierarchy is specified with a maximum of five levels. If
due to special circumstances this restriction is not practical, this should be justified in the
application and approval should be obtained from the administration PCA.
page 166
The policy certification authority (PCA) provides the certificates and revocation lists issued
by it in the public access part of the X.500 directory of the IVBB (Berlin-Bonn Information
Network)277. The availability of this directory fulfils the IVBB's high requirements on availability. Detailed information concerning layout and access can be found in the directory concept of the administration PCA.
In order to leave PKI use open to other existing communication relations with other
governments, businesses and citizens, the European Bridge CA (EB-CA) under the leadership of TeleTrusT Deutschland e.V. offers an organization-spanning solution. This solution
links the PKIs of business and administration to each other and is designed to achieve maximum interoperability and flexibility. As the operator of the Policy Certification Authority of
the administration PKI, the German Federal Office for Information Security (BSI) represents
the public administration of the Federal Republic of Germany within the EB-CA.
A.10.3.1 Technical specification of services
The policy certification authority operated by the BSI issues certificates applied for by all
certification authorities from the field of public administration (Federal Government,
federal states, municipalities).
Since the evaluation of the trustworthiness of the certificates issued is of vital importance
for a PKI, binding security guidelines (policy) are described in one document for the certification authorities. The layout of this document is based on the recommendations of the
RFC 2527 whilst combining both elements of a policy and certificate practice statements
(CPSs) which are more orientated towards the technical organization.
Certificates can be issued by certification authorities as certificates issued for a person or a
group. Group certificates can be issued for the following:
a. Groups of individuals (e.g. PKI project group)
b. Functions (e.g. post office; functions which are carried out by an employee)
c. Automated IT processes (e.g. electronic stamp, server process with signature, SSL server)
The area of application within the scope of this policy for certificates of the administration
PKI ranges from encryption and authentication to the advanced electronic signature within
the meaning of the German Signature Act (SigG).
Within the scope of the V-PKI infrastructure, the policy certification authority is responsible
for the following:
a. Generation of a suitable cryptographic key pair in a secure environment
b. Generation of a self-signed certificate
c. Trusted and authentic publication:
i.
of its certificate, including the pertinent fingerprint
277. Refer to section A.2 "OFA service – Directory service" on page 126
page 167
ii. of the certificates issued by it
iii. of revocation lists from certification authorities
d. Adherence to the policy
e. Provision of a revocation service
Apart from these services, the V-PKI is integrated into the German economy via the European Bridge CA whereby the policy certification authority (PCA) represents the public
administration user group. In addition to this, event-based interoperability tests are conducted for PKI products and the results are published together with a recommendation for
suitable products.
Encrypted e-mail communication
The user wants confidential communication via e-mail. To achieve this, either the entire
e-mail can be encrypted or merely a file that is attached to the e-mail. Encryption takes
place via the so-called public key method. In this case, the user receives a private and public
key from a certification authority within the V-PKI. The reliable assignment of the public key
to the user is carried out via electronic certificates. For this purpose, the certificate and the
public key are made publicly available in the X.500 directory service of the IVBB.
Signed e-mail communication
A user wishes to ensure the binding nature of his e-mail, i.e. its authenticity and the integrity of the data. To achieve this, he uses his private key of the public-key method as described above and creates a signature. This is a short value that cannot be manipulated which
is attached to the original data and which can be checked by the recipient using the public
key.
Encrypted communication on the web
A public agency wishes to transmit to the user an (interactive) offer of its website via a secured channel. In order to achieve SSL encryption and hence confidential transmission of the
data between the web server and browser, a server certificate of a V-PKI certification authority is used.
A.10.4 Interfaces
The widespread use of the services and systems within a PKI is only possible with widespread interoperability which ensures the exchange of PKI information (user certificates, CA
certificates and revocation lists). The standards (ISIS-MTT278) used here by the policy certification authority and all other users become binding through the security guidelines for the
entire PKI.
278. Refer to section 9.3 "Implementation of the security concept" on page 108
page 168
The administration PKI is based on the MailTrusT specification by TeleTrusT Deutschland
e.V., version 2 (MTT v2). This ensures interoperability with standards that are used on an
international scale, e.g. S/MIME, X.509 and LDAP. Future migration to generally valid standards, such as ISIS-MTT, will be carried out in line with development progress.
A.10.5 Operation
Information concerning features is defined in the respective policies of the CAs / PCA.
A.10.6 Users and conditions of access
All federal-government, federal-state and municipal public institutions can participate in
the V-PKI with a CA if the policy requirements are fulfilled.
(End) users receive certificates from "their" CA.
This applies to public service employees and, in exceptional cases, employees in companies
and/or service providers if this is of interest from a public service point of view. Private individuals are not considered up to now.
A.10.7 Connected users
Up to now, public service employees and company employees are connected.
All participating CAs are listed in the IVBB directory along with their certificates. For reasons
of data protection, BSI has no knowledge of and no access to the (end) user certificates
issued by the CAs.
A.10.8 Outlook
The V-PKI policy (with the pertinent documents) will undergo comprehensive revision.
Some items which should be mentioned here include:
a. Splitting up the Root Policy into two documents (RFC-3647-compliant): PCA policy and
policy requirements for participating CAs
b. The foundation is no longer MailTrusT, but ISIS-MTT
c. Longer certificate terms for PCA and CAs
d. User key can be re-certified if on a smartcard with a key length of 2048 bits as specified
by the German Signature Act
page 169
page 170
Appendix B Bibliography
[APEC]
National Office for the Information Economy / CSIRO: APEC e-Business: What do Users
need?, 2002
http://pandora.nla.gov.au/tep/25067/
http://www1.cmis.csiro.au/Reports/APEC_E-commerce.pdf
[BOL]
Bundesministerium des Innern (Hrsg.): Umsetzungsplan für die eGovernment-Initiative
BundOnline 2005, Dresden 2004
http://www.kbst.bund.de/ (im Bereich > E-Government > Initiativen > BundOnline 2005
> Umsetzungsplan und Abschlussbericht > Umsetzungsplan 2004)
[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, 1985-2005
http://www.itl.nist.gov/fipspubs/
[IDABC]
European Commission: Interoperable Delivery of European eGovernment Services to public
Administrations, Businesses and Citizens, 2005
http://europa.eu.int/idabc/
[IEEE2000]
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, Genf 1996
[ITG 2000]
Informationstechnische Gesellschaft (ITG) im VDE: Electronic Government als Schlüssel
der Modernisierung von Staat und Verwaltung. Ein Memorandum des Fachausschusses
für Verwaltungsinformatik der Gesellschaft für Informatik e.V. (GI) und des
Fachbereichs 1 der Informationstechnischen Gesellschaft (ITG) im Verband der Elektrotechnik, Elektronik und Informationstechnik (VDE), Bonn / Frankfurt 2000
http://mediakomm.difu.de/documents/memorandum.pdf
page 171
[Kudraß 1999]
Kudraß, Thomas: Describing Architectures Using RM-ODP, Online-Publikation, 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,
Vortrag auf der 4. Fachtagung Verwaltungsinformatik in der Fachhochschule des Bundes für öffentliche Verwaltung am 5. September 2001
[v. Lucke et al. 2000]
Lucke, Jörn von / Reinermann, Heinrich: Speyerer Definition von Electronic Government.
Ergebnisse des Forschungsprojektes Regieren und Verwalten im Informationszeitalter,
Online-Publikation, 2000
http://foev.dhv-speyer.de/ruvii/Sp-EGov.pdf
[Neuseeland]
E-government Unit, State Services Commission, New Zealand: New Zealand E-government Programme Home Page, 2005
http://www.e-government.govt.nz/
[Schedler et al. 2001]
Schedler, Kuno / Proeller, Isabella: NPM, Bern / Stuttgart / Wien 2001
[Schreiber 2000]
Schreiber, Lutz: Verwaltung going digit@l. Ausgewählte Rechtsfragen der Online-Verwaltung, in: Digitale Signaturen, in: Kommunikation & Recht Beilage 2 zu Heft 10/2000
[Schweiz]
Schweizerische Bundeskanzlei: CC Web BK – Kompetenzzentrum elektronischer Behördenverkehr, Homepage der Beratungs-, Dienstleistungs- und Betriebsorganisation für den
elektronischen Behördenverkehr (E-Government), 2005
http://www.admin.ch/ch/d/egov/index.de.html
page 172
Appendix C Overview of Classified Standards
Advanced Encryption Standard (AES) .........................................................................113
Animated GIF ..............................................................................................................92
Application profile CSW-DE v1.0.1 ................................................................................99
ArchiSig, principles for conclusive and secure long-term archiving of electronically signed
documents ...............................................................................................................103
Barrier-free information technology ordinance (BITV) ....................................................82
BSI, eGovernment manual .................................................................................108, 109
BSI, IT Baseline Protection Catalogues ........................................................................107
BSI-Standard 100-1: Management systems for Information Security (ISMS) v1.0 ............107
BSI-Standard 100-2: IT baseline protection approach v1.0 ....................................105, 107
BSI-Standard 100-3: Risk analysis on the basis of IT baseline protection v2.0 .................107
Business Process Execution Language for Web Services (BPEL4WS) v1.1 .......................102
Cascading Style Sheets Language Level 2 (CSS2) ...........................................................83
Catalogue Service (CAT) v2.0.1 .....................................................................................99
Character Separated Value (CSV) ..................................................................................87
Cryptographic algorithms for the electronic signature according to the Federal Network
Agency .....................................................................................................................111
Digital Signature Algorithm (DSA) ..............................................................................112
Directory Services Markup Language (DSML) v2 ............................................................99
Domain Name Services (DNS) ......................................................................................97
Dublin Core ................................................................................................................76
ECMA-262 – ECMAScript Language Specification ..........................................................84
Election Markup Language (EML) v4.0 ..........................................................................75
Entity Relationship Diagram .........................................................................................74
Extensible Hypertext Markup Language (XHTML) Basic .................................................93
Extensible Hypertext Markup Language (XHTML) v1.0 ...................................................83
Extensible Markup Language (XML) v1.0 .............................................. 75, 101, 102, 103
Extensible Markup Language (XML) v1.1 .............................................. 75, 101, 102, 104
Extensible Stylesheet Language (XSL) v1.0 ..............................................................83, 84
Extensible Stylesheet Language Transformations (XSLT) v1.0 .........................................75
File Transfer Protocol (FTP) ..........................................................................................97
Geo Tagged Image File Format (GeoTIFF) .....................................................................89
Geography Markup Language (GML) v2.1.2 ..................................................................90
Geography Markup Language (GML) v3.1.1 ..................................................................89
page 173
Graphics Interchange Format (GIF) ...............................................................................88
GZIP v4.3 ....................................................................................................................93
Hypertext Markup Language (HTML) v4.01 ....................................................... 82, 85, 87
Hypertext Transfer Protocol (HTTP) v1.1 ................................................................. 91, 98
Industrial Signature Interoperability Specification - MailTrusT (ISIS-MTT) v1.1 ...... 108, 110,
114, .........................................................................................................................115
Internet Message Access Protocol (IMAP) .....................................................................98
Internet Protocol (IP) v4 ...............................................................................................97
Internet Protocol (IP) v6 ...............................................................................................97
ISO/IEC 7816 .............................................................................................................110
J2EE Connector Architecture (JCA) v1.5 ........................................................................95
Java 2 Platform, Enterprise Edition (J2EE) v1.4 ...............................................................77
Java 2 Platform, Standard Edition (J2SE) v1.4 ................................................................78
Java Database Connectivity (JDBC) v3.0 ......................................................................102
Java Message Service (JMS) v1.1 ...................................................................................95
Java Network Launching Protocol (JNLP) v1.5 ...............................................................78
Java Platform, Enterprise Edition (Java EE) v5 ................................................................78
Java Platform, Standard Edition (Java SE) v5 .................................................................78
Java Server Pages (JSP) v2.0 .........................................................................................84
Java Server Pages (JSP) v2.1 .........................................................................................84
Joint Photographic Experts Group (JPEG) ............................................................. 88, 103
Joint Photographic Experts Group 2000 (JPEG2000) / Part 1 ..........................................89
Kerberos v5 ..............................................................................................................109
KoopA ADV, Guideline for the Introduction of the Electronic Signature and Encryption in the
Administration v1.1 ...................................................................................................107
Lightweight Directory Access Protocol (LDAP) v3 ..........................................................98
Microsoft Windows .NET Framework v2.0 .....................................................................78
MPEG-4 Part 14 ..................................................................................................... 90, 92
Multipurpose Internet Mail Extensions (MIME) v1.0 ................................................. 85, 98
Ogg ...................................................................................................................... 90, 92
Online Service Computer Interface (OSCI)-Transport v1.2 ............................................116
Open Document Format for Office Applications (OpenDocument) v1.0 ............. 86, 87, 88
PHP: Hypertext Preprocessor (PHP) v5.x ........................................................................79
Portable Document Format (PDF) v1.4 ............................................................. 85, 86, 87
Portable Document Format (PDF) v1.5 ................................................................... 85, 87
Portable Document Format (PDF) v1.6 ............................................................. 85, 87, 88
page 174
Portable Document Format Archive (PDF/A) ...............................................................104
Portable Network Graphics (PNG) .................................................................................88
Post Office Protocol (POP) 3 .........................................................................................98
Quicktime (.qt, .mov) .............................................................................................90, 91
RealMedia v10 (.rm, .ram) .......................................................................................91, 92
Regular Language Description for XML New Generation (Relax NG) ................... 74, 95, 96
Remote Method Invocation (RMI) .................................................................................94
Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) .........................95
Resource Description Framework (RDF) ........................................................................76
RIPE Message Digest (RIPEMD)-160 ............................................................................111
Role models and flow charts ........................................................................................73
RSA ..........................................................................................................................112
Secure Hash Algorithm (SHA)-224 ..............................................................................111
Secure Shell v2 (SSH-2) ..............................................................................................114
Security Assertion Markup Language (SAML) v2.0 .......................................................109
Servlets .......................................................................................................................84
Short Message Services (SMS) ......................................................................................93
Simple Feature Access – Part 2: SQL option (SFA-2) v1.1.0 ............................................100
Simple Mail Transfer Protocol (SMTP) ...........................................................................98
Simple Object Access Protocol (SOAP) v1.1 .............................................................94, 96
Synchronized Multimedia Integration Language (SMIL) v2.0 ..........................................88
Tagged Image File Format (TIFF) v6.0 ...................................................................89, 103
Text (.txt) ....................................................................................................................86
Transport Layer Security (TLS) v1.0 .............................................................................113
Transport Layer Security (TLS) v1.1 .............................................................................114
Unicode v4.x UTF-16 ....................................................................................................83
Unicode v4.x UTF-8 .....................................................................................................83
Unified Modeling Language (UML) v2.0 ..................................................................73, 74
Universal Description, Discovery and Integration (UDDI) v2.0 ..................................96, 98
Web Coverage Service (WCS) v1.0.0 ............................................................................100
Web Feature Service (WFS) v1.0.0 ...............................................................................100
Web Feature Service (WFS) v1.1.0 ...............................................................................100
Web Map Service (WMS) v1.1.1 ....................................................................................99
page 175
Web Map Service (WMS) v1.3.0 ..................................................................................100
Web Services ............................................................................................................102
Web Services (WS)-Security v1.1 .................................................................................116
Web Services Description Language (WSDL) v1.1 .................................................... 94, 96
Windows Media Video (.wmv) v9 ........................................................................... 91, 92
Wireless Application Protocol (WAP) v2.0 .....................................................................93
WWW Distributed Authoring and Versioning (WebDAV) ................................................98
XForms v1.0 ................................................................................................................84
XML Encryption ........................................................................................................115
XML Key Management Specification (XKMS) v2 ...........................................................110
XML Metadata Interchange (XMI) v2.x .................................................................... 73, 74
XML Schema Definition (XSD) v1.0 ................................................................... 74, 95, 96
XML Signature ..........................................................................................................115
ZIP v2.0 ......................................................................................................................93
page 176
Appendix D List of abbreviations
3DES
Triple Data Encryption Standard
AES
Advanced Encryption Standard
AG
Public limited company in Germany
AP
Associated Press
APEC
Asia-Pacific Economic Cooperation
API
Application Programming Interface
ArchiSig
Conclusive and secure long-term archiving of electronically signed documents
ASP
Application Service Providing
ATKIS
Official Topographical-Cartographical Information System
AZR
Central Aliens' Register
BA
Federal Employment Agency
BakÖV
Federal Academy of Public Administration
BAM
Federal Institute for Materials Research and Testing
BBR
Federal Office for Building and Regional Planning
BeschA
Procurement Office of the Federal Ministry of the Interior
BfA
Federal Insurance Institute for Salaried Employees
BfN
Federal Agency for Nature Conservation
BGG
Law on equal opportunities for the disabled
BHO
Federal Budget Code
BIT
Federal Office for Information Technology in the Federal Administration
BITV
Barrier-free information technology ordinance
BKG
Federal Centre for Cartography and Geodesy
BMAS
Federal Ministry for Labour and Social Affairs
BMBF
Federal Ministry of Education and Research
BMF
Federal Ministry of Finance
BMI
BMP
Windows Bitmap
BMWi
Federal Ministry of Economics and Technology
BNetzA
Federal Network Agency for electricity, gas, telecommunications, post and
railways
page 177
BOL
BundOnline 2005 Initiative
BpB
Federal Agency for Civic Education
BPEL4WS
Business Process Execution Language for Web Services
BSH
Federal Maritime and Hydrographic Agency
BSI
German Federal Office for Information Security
BVA
Federal Office of Administration
BVerwG
Federal Administrative Court
BVN
Federal Administration Network
BZR
Federal Central Criminal Register
CA
Certification Authority
CAT
Catalogue Service
CC VBPO
The "workflow management, processes and organization" competence
center
CEN
Comité Européen de Normalisation
CITES
Convention on International Trade in Endangered Species of Wild Fauna and
Flora
CMS
Content Management System
CORBA
Common Object Request Broker Architecture
CPS
Certificate Practice Statement
CPU
Central Processing Unit
CRL
Certificate Revocation List
CSIRO
Commonwealth Scientific and Industrial Research Organisation
CSS
Cascading Style Sheets Language
CSV
Character Separated Value
CSW
Web Catalogue Service
CVC
Card Verification Code
DCMI
Dublin Core Metadata Initiative
DES
Data Encryption Standard
DI
Document Interface
DIMDI
German Institute for Medical Documentation and Information
DIN
German industrial standard
DMZ
Demilitarized Zone
DNS
Domain Name Services
page 178
DOMEA
Document management and electronic archiving" in IT-based workflows
DPA
German press agency
DSA
Digital Signature Algorithm
DSML
Directory Services Markup Language
DSS
Digital Signature Standard
DV
Data processing
DWD
German Meteorological Service
EAI
Enterprise Application Integration
EB-CA
European Bridge CA
ebXML
Electronic Business XML
ECMA
European Computer Manufacturers Association
ECMS
Enterprise Content Management System
e-GIF
E-Government Interoperability Framework
EGVP
Electronic mailbox for courts and public administrations
EJB
Enterprise JavaBeans
EML
Election Markup Language
ER
Entity Relationship
ERP
Enterprise Resource Planning
EStdIT
Development standard for federal administration IT systems
ETSI
European Telecommunications Standards Institute
EU
European Union
FAQ
Frequently Asked Questions
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
page 179
GI
Gesellschaft für Informatik e.V.
GIF
Graphics Interchange Format
GIS
Geo-information system
GML
Geography Markup Language
GSB
Government Site Builder
GSM
Global System for Mobile Communications
HKR
Federal Budgeting and Accountancy Service
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
HTTPS
Secure Hypertext Transfer Protocol
IDABC
Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens
IEC
International Electrotechnical Commission
IETF
Internet Engineering Task Force
IIOP
Internet Inter-ORB Protocol
IMAGI
Inter-ministerial Committee for Geo Information
IMAP
Internet Message Access Protocol
IP
Internet Protocol
IPsec
IP-Security Protocol
IPTC
International Press Telecommunications Council
ISIS
Industrial Signature Interoperability Specification
ISO
International Organization for Standardization
IT
Information technology
ITG
IT society
ITIL
IT Infrastructure Library
IVBB
Berlin-Bonn Information Network
IVBV
Federal Administration Information Network
J2EE
Java 2 Platform, Enterprise Edition
J2SE
Java 2 Platform, Standard 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
page 180
JAXR
Java API for XML Registries
JCA
J2EE Connector Architecture
JRC
Joint Research Centre
JDBC
Java Database Connectivity
JMS
Java Message Service
JMX
Java Management Extensions
JNDI
Java Naming and Directory Interface
JNLP
Java Network Launching Protocol
JPEG
Joint Photographic Experts Group
JRE
Java Runtime Environment
JSP
Java Server Pages
JSR
Java Specification Requests
JTA
Java Transaction API
JURIS
Legal Information System for the Public Administration
KBA
Federal Motor Transport Authority
KBSt
Co-ordinating and Advisory Agency of the Federal Government for Information Technology in the Federal Administration at the Federal Ministry of the
Interior
KDE
K Desktop Environment
KoopA ADV
Co-operation Committee for Automatic Data Processing for the Federal Government, 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
MPLS
Multi Protocol Label Switching
MTT
MailTrusT
NAT
Network Address Translation
NISO
National Information Standards Organization
NIST
National Institute of Standards and Technology
NKZ
Network competence center of the German Meteorological Service
page 181
NRW
North-Rhine Westphalia
OASIS
Organization for the Advancement of Structured Information Standards
OCR
Optical Character Recognition
OCSP
Online Certificate Status Protocol
OFA
One-for-all
OGC
Open GIS Consortium
OMG
Object Management Group
OSCI
Online Services Computer Interface
OSI
Open Systems Interconnection
OSS
Open Source Software
PC
Personal Computer
PCA
Policy Certification Authority
PDA
Personal Digital Assistant
PDF
Portable Document Format
PDF/A
PDF Archive
PGP
Pretty Good Privacy
PHP
PHP: Hypertext Preprocessor
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
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
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
page 182
RSA
Rivest, Shamir, Adleman Public Key Encryption
RSS
Really Simple Syndication
SAGA
Standards and Architectures for eGovernment Applications
SAML
Security Assertion Markup Language
SC
Service Center
SDSL
Symmetric Digital Subscriber Line
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
SINA
Secure Inter-Network Architecture
SL
Standard solution
SMIL
Synchronized Multimedia Integration Language
S/MIME
Secure Multipurpose Internet Mail Extensions
SMS
Short Message Service
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
Sub-CA
Subordinated Certification Authority
TAN
Transaction number
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
TN
User
Triple-DES
Triple Data Encryption Standard
page 183
TSP
Time Stamp Protocol
UDDI
Universal Description, Discovery and Integration
UDP
User Datagram Protocol
UML
Unified Modeling Language
UMTS
Universal Mobile Telecommunication System
UN/CEFACT
United Nations Centre for Trade Facilitation and Electronic Business
UTF
Unicode Transformation Format
VDE
Association for Electrical, Electronic and Information Technologies
VLAN
Virtual Local Area Network
VM
Virtual Machine
V-Modell
Procedure model
V-PKI
Administration Public Key Infrastructure (Administration PKI)
VPN
Virtual Private Network
VPS
Virtual post office
W3C
World Wide Web Consortium
WAP
Wireless Application Protocol
WCAG
Web Content Accessibility Guideline
WCS
Web Coverage Service
WebDAV
WWW Distributed Authoring and Versioning
WFS
Web Feature Service
WMC
Web Map Context
WML
Wireless Markup Language
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-S
Web Service Security
WSV
Waterway and Shipping Administration
WWW
World Wide Web
XHTML
Extensible Hypertext Markup Language
page 184
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 in the public administration
XSD
Extensible Markup Language Schema Definition
XSL
Extensible Stylesheet Language
XSLT
Extensible Stylesheet Language Transformations
ZIVIT
Centre for information process and IT
ZÜV
Payment monitoring system
ZVP
Payment platform
page 185

SAGA 3.0 - IT-Beauftragter der Bundesregierung

Transcription

Similar documents

Secret Norway brochure

eGovernment Strategy 2007-2010

Batch Production of Driving Distances and Times Using SAS® and

Animals Toy Horses Toy horses are common enough to deserve

TOURISTIC BROCHURE 2015

-eGov Research v6.qxd - Government Executive

THE RETRIEVER BELIEVER - Puget Sound Labrador Retriever

Important Performance Analysis, SWOT, EFAS, IFAS

LavaCon Final Program.book

The Next Phase of Digital Government

How I learned to love XML! (FME Certified Professional, Peter

with the cover page - École des Mines de Saint