SAGAStandards and Architectures for eGovernment Applications

Version 4.0

March 2008

2 SAGA 4.0

Reprint, even in part, subject to approval

This volume was prepared by the Federal Ministry of the Interiorin co-operation with ]init[ AG and Fraunhofer-Institut für Software- und Systemtechnik (ISST).

Homepage and download of the digital version: http://www.cio.bund.de/saga

mail to: IT2@bmi.bund.de

SAGA 4.0 3

SAGAStandards and Architectures for eGovernment Applications

Version 4.0

March 2008

Published by the Federal Ministry of the Interior

4 SAGA 4.0

SAGA 4.0 5

Word of thanks

The Federal Ministry of the Interior and the SAGA authors would like to thank the representatives from the federal states and municipalities in the KoopA-SAGA project group, the representatives from the central IT service providers of the federal administration along with all the members of the SAGA expert group for their support during the preparation of this version of SAGA.

We would also like to extend our thanks to all those who have made use of the SAGA forum and the SAGA contact form and whose committed comments constituted a valuable contribution towards updating the document.

6 SAGA 4.0

Introduction:

This document presents in concise form widely used standards, processes, and methods of state-of-the-art IT development for eGovernment applications. Due to the nature of this subject, experts in this sector use many abbreviations and, in most cases, English acronyms. Some of these names are protected by copyright and/or are registered trademarks, or are products of certain manufacturers or standardization organizations that are protected at national and international level.

In the interest of a simple structure, copyright and source references of this kind were generally omitted. The use of a "name" or abbreviation in this document does not mean that they are free from copyrights or intellectual property rights of third parties.

Furthermore, neither the editor, the authors nor the experts consulted can accept any responsibility for the technical functioning, compatibility or completeness of the standards discussed. This version 4.0 was published in October 2007. Please send any comments, amendments or corrections to: Bundesministerium des Innern, Referat IT2. These comments, amendments or corrections can also be published on the SAGA forum at http://www.cio.bund.de.

Version numbers are stated when they are relevant in the specific context discussed. If no version numbers of standards are stated, the version which is most stable from a market point of view should be used, even though this may not necessarily be the latest version.

The authors permit the further use of this document - even in part - on condition that it is quoted as the source.

A general demand for SAGA conformance is not enough in order to achieve the goals of SAGA. Due to the complexity of the document, a general demand leaves too much room for interpretation and misunderstanding. This makes it difficult for the supplier to fulfil the requirements and for the customer to check that requirements are fulfilled. To find out more about the correct handling of SAGA conformance, please refer to section 2.4 on page 25, and for further assistance, go to: http://www.cio.bund.de/saga.

In the time since the first publication of SAGA 4.0 the website http://www.kbst.bund.de/saga was moved to http://www.cio.bund.de/saga. Therefore some of the links given in this document are no longer valid. For information on SAGA please refer to http://www.cio.bund.de/saga.

SAGA 4.0 7

Table of Contents0 Status, revision history and outlook..................................................................................................9

0.1 Amendments to version 3.0................................................................................................................9

0.2 Future issues.........................................................................................................................................10

1 Introduction..........................................................................................................................................11

1.1 Background...........................................................................................................................................11

1.2 Readers of this document...................................................................................................................11

1.3 Aims........................................................................................................................................................12

1.4 Tasks.......................................................................................................................................................12

1.5 Basic principles for eGovernment applications.............................................................................13

1.6 Relationships with other eGo vern ment documents .....................................................................13

1.7 The evolution process.........................................................................................................................17

1.8 Structure of the document.................................................................................................................18

2 Fundamentals of SAGA.......................................................................................................................19

2.1 Scope of validity and binding effect of SAGA..................................................................................19

2.2 Minimum requirements with regard to the openness of standards.........................................20

2.3 Classification and life cycles of standards.......................................................................................20

2.4 SAGA conformance.............................................................................................................................25

3 Architecture model for eGovernment applications......................................................................31

3.1 Overview...............................................................................................................................................31

3.2 Enterprise viewpoint..........................................................................................................................32

3.3 In for ma tion view point .......................................................................................................................33

3.4 Com pu ta tio nal view point .................................................................................................................34

3.5 Engineering viewpoint......................................................................................................................34

3.6 Technology viewpoint........................................................................................................................34

4 Enterprise viewpoint: Fundamentals of eGovernment...............................................................35

4.1 Definitions of eGovernment in Germany.......................................................................................35

4.2 The philosophy underlying eGovernment.....................................................................................36

4.3 Strategic goals......................................................................................................................................37

4.4 Organizational requirements...........................................................................................................41

4.5 Legal frame of reference....................................................................................................................45

4.6 Processes in eGovernment................................................................................................................49

4.7 Modules for the implementation of eGovernment applications...............................................52

5 In for ma tion view point: Standardization of data models ............................................................55

5.1 Levels of interoperability...................................................................................................................55

5.2 Purpose of standardizing data models...........................................................................................56

5.3 The Deutschland-Online "Standardisierung" [Standardization] project.................................57

5.4 Support for data model developers.................................................................................................59

6 Com pu ta tio nal view point: Reference soft ware architecture ....................................................65

6.1 General requirements for software applications..........................................................................65

6.2 Implementation options and architecture paradigms................................................................67

8 SAGA 4.0

6.3 Reference software architecture for eGovernment applications...............................................72

7 Engineering viewpoint: IT service management and reference infrastructure.....................79

7.1 IT Service Management with the ITIL..............................................................................................79

7.2 Design of an eGovernment infrastructure.....................................................................................84

7.3 Networks as the link between an infrastructure and external services and users..................88

7.4 Access to external services................................................................................................................88

8 Technology Viewpoint: Standards for IT architecture and data security..................................91

8.1 IT security concept..............................................................................................................................91

8.2 Process models....................................................................................................................................95

8.3 Data models.........................................................................................................................................96

8.4 Application architecture...................................................................................................................98

8.5 Client....................................................................................................................................................101

8.6 Presen tation .......................................................................................................................................105

8.7 Communication.................................................................................................................................121

8.8 Backend...............................................................................................................................................130

8.9 Encryption..........................................................................................................................................132

8.10 Electronic signature..........................................................................................................................133

8.11 Smartcards..........................................................................................................................................135

8.12 Long-term archiving.........................................................................................................................136

Appendix A References..........................................................................................................................................139

Appendix B Overview of Classified Standards....................................................................................................143

Appendix C Abbreviations.....................................................................................................................................153

SAGA 4.0 9

0 Status, revision history and outlook

0.1 Amendments to version 3.0This document is a revised version of SAGA, version 3.0. The following changes have been made:

In chapter 2 "Fundamentals of SAGA", the names of the lists for the extended classification of technical standards outside the document (White List, Grey List, Black List) were replaced with new names (List of Suggestions, Right of Continuance List, Negative List)1.

Chapter 4 "Enterprise viewpoint: Fundamentals of eGovernment" has been re-organized. The terms "eGovernment" and "service" are now more clearly defined2. This chapter was also extended to include the topics of "eGovernment 2.0"3, "Deutschland-Online"4, "Germany as a member of the European Union"5, the "EU service directive"6 and the "Federal government's signature projects and initiatives"7 .

Chapter 5 "Information viewpoint: Standardization of data models" was revised with a view to the Deutschland-Online "Standardization"8 project and the topics of XGenerator 2.09 and Core Components10.

Chapter 6 "Computational viewpoint: Reference software architecture" now also includes sections on architecture decisions11 and information addressing the introduction of service oriented architectures12.

Chapter 7 "Engineering viewpoint: IT service management and reference infrastructure" introduces the "IT Infrastructure Library" (ITIL) as best practice for IT service management13. In addition to this, the Deutsches Verwaltungsdiensteverzeichnis (DVDV) [German Directory of Administrative Services] is presented in more detail14.

The previous chapter 8 “Technology viewpoint (part I): Standards for the IT architecture" and chapter 9 "Technology Viewpoint (part II): Standards for data security" were combined

1 Refer to section 2.3.2 "Extended classification of standards" on page 212 Refer to section 4.1 "Definitions of eGovernment in Germany" on page 353 Refer to section 4.3.1 "eGovernment 2.0 – A Federal Government programme" on page 374 Refer to section 4.3.2 "Deutschland-Online - The joint eGovernment strategy of the Federal

Government, federal-state governments and municipalities." on page 385 Refer to section "Germany as a member of the European Union" on page 436 Refer to section 4.5.4 "EU services directive – Creating a single EU market" on page 487 Refer to section "Federal Government initiatives and projects in the field of electronic

signatures" on page 468 Refer to section 5.3 "The Deutschland-Online "Standardisierung" [Standardization] project"

on page 579 Refer to section 5.4.3 "XGenerator 2.0" on page 6210 Refer to section 5.4.4 "Core components" on page 6311 Refer to section 6.3.1 "Architecture decisions" on page 7212 Refer to section 6.3.2 "Introduction of a service oriented architecture" on page 7313 Refer to section 7.1 "IT Service Management with the ITIL" on page 7914 Refer to section 7.4.1 "Deutsches Verwaltungsdiensteverzeichnis [German Directory of

Administrative Services]" on page 88

10 SAGA 4.0

to form chapter 8 "Technology viewpoint: Standards for IT architecture and data security". Moreover, products and implementations were persistently replaced by the underlying standards. The previous positive list of supported plug-ins was replaced by a list of requirements which plug-ins should fulfil in the federal administration's eGovernment applications. The topics of "IP telephony"15 and "Registries"16 were re-introduced and the topic of "Smartcards"17, which was already addressed in SAGA 3.0, was dealt with in more detail.

SAGA 4.0 no longer features a separate appendix for the one-for-all offers (OFA offers) by the federal administration. The OFA offers will be soon described and will be updated outside of SAGA on the KBSt18 homepage and/or on the homepage of the individual OFA offers, respectively. The definitions of OFA service, OFA system, infrastructure and OFA concept were moved to chapter 619.

Furthermore, this version also features a response to the further development of standards. Standards were accepted from the List of Suggestions (former White List), the classification of existing standards was changed and standards were moved from the document to the Right of Continuance List (former Grey List20).

0.2 Future issuesThe following topics are to be examined and dealt with in more detail in the next version of SAGA:

a. Development and standardization of process and data models

b. IT service management on the basis of the "IT Infrastructure Library" (ITIL) v3.0

c. Long-term archiving of dynamic information from databases and websites

d. Communication per instant messaging and chat

e. Exchange and visualization of 3D data

Besides the SAGA document, the Federal Ministry of the Interior also provides additional information, links and tools on the web21.

15 Refer to section 8.7.4 "IP telephony" on page 12516 Refer to section 8.8.1 "Directory services and registries" on page 13017 Refer to section 8.11.2 "Contactless smartcards" on page 135 and section 8.11.3 "Reader units

and interfaces for smartcards" on page 13618 Refer to http://www.kbst.bund.de/efa 19 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 7620 With regard to the definition of White List and Grey List, refer to section 2.3.2 on page 2121 Refer to http://www.kbst.bund.de/saga

SAGA 4.0 11

1 Introduction

1.1 BackgroundIn an effort to create a more modern and service-orientated administration, the Federal Government is implementing more and more administration processes electronically. The application of eGovernment is making it possible for citizens, business and administrations to handle matters both faster and more efficiently. Standards are needed in order to enable these many different applications for the future and accessible for all. This is guaranteed by the Standards and Architectures for eGovernment Applications (SAGA) guideline.

Shortly after the launch of the nation-wide BundOnline Initiative, the Co-ordinating and Advisory Agency of the Federal Government for Information Technology in the Federal Administration (KBSt) made this document available for the first time in 2002. Since then, SAGA has been helping public agencies to achieve the goal of the initiative and to offer more than 400 online services with Internet capability.

On the basis of this success, the SAGA expert group continuously accompanies work on the standards. In this version 4.0, central IT service providers from the federal administration were involved for the first time in updating the guideline. The latest developments and experience are being added to the document through the discussion in the public SAGA forum. In close co-operation with a KoopA-SAGA project group22, the specific requirements of the federal states and municipalities are also being included. With this knowledge, the SAGA authors regularly prepare an updated version with the Federal Ministry of the Interior which is in charge of content.

A host of completed projects has now been orientated towards the state-of-the-art and investment-safe standards and technologies recommended by SAGA. Many federal agencies use SAGA to plan and implement their IT projects, so that they can shape the interoperability of the various planned and existing applications.

Widespread acceptance and especially growing interest among federal states and municipalities are proof that SAGA is becoming increasingly important for eGovernment in Germany. In this version 4.0, SAGA once again offers a guideline for the economic and future-orientated implementation of IT projects in administrations.

1.2 Readers of this documentSAGA is primarily designed for decision-makers in the fields of organization, information technology and eGovernment teams in German administrations. The document is a guideline that serves as an orientation aid when it comes to developing concepts for technical architectures and general technical concepts for individual IT applications.

22 KoopA ADV = Co-operation Committee for Automatic Data Processing for the Federal-government, Federal-state Government and Municipal Administration Sector

12 SAGA 4.0

Application developers should feel free to seek further detailed solutions whenever the standards and solution proposals presented herein are not sufficient for the implementation of technical requirements.

The Federal Government also sees its initiative as a contribution towards the development of eGovernment in Germany. The experience gained within the scope of the initiative should help to promote nation-wide, inter-agency eGovernment offers.

1.3 AimsSAGA pursues the following aims:

a. Interoperability – Warranting co-operation between various eGovernment applications in order to effectively exchange information between the Federal Government, citizens, businesses and partners of the Federal Government

b. Reusability – re-use of process and data models, systems, services and components in various eGovernment projects in order to generate synergies

c. Openness – Inclusion of open standards in eGovernment applications in order to promote their long-term usability23

d. Reduction of costs and risks – Considering investment-safe developments on the market and in the field of standardization

e. Scalability – Ensuring the usability of applications as requirements change in terms of volume and transaction frequency

1.4 TasksSAGA pursues a comprehensive standardization approach for Germany's administrations in order to achieve the following goals.

Defining technical Standards and Architectures for eGovernment Applications

The technical standards and architectures cover all the levels and elements relevant for eGovernment. They form the basis for the interoperability and compatibility of the eGovernment applications to be developed.

Standardizing processes and data in administrations

In order to achieve interoperability and compatibility of eGovernment applications, it is necessary to create a basis for standardizing processes and data in Germany's administrations. In an effort to support this, systems and services are described on the KBSt website which can be used as modules (one-for-all offerings24) in eGovernment applications.

23 Refer to section 2.2 "Minimum requirements with regard to the openness of standards" on page 20

24 OFA offering and networks: http://www.kbst.bund.de/efa

SAGA 4.0 13

1.5 Basic principles for eGovernment applications

eGovernment applications are designed to fully reach their target groups. This is why it should be possible to access all the functions irrespective of the users' selected platform, the configuration of the user systems or the abilities of the users. eGovernment applications must be orientated towards the requirements and needs of the target groups.

On the basis of these preconditions, the following basic principles are laid down for eGovernment applications:

a. eGovernment applications primarily use the web browser as the front-end, unless the services to be implemented cannot be reasonably handled via a browser.

b. They do without active contents so that users are not forced to reduce the browser's security settings and thus to make damage by invisible websites possible, or at least use only signed and quality-secured applications of the type contemplated in the section 8.5.1 "Access to information with computers” on page 101.

c. eGovernment applications do not store any program parts or data on the users' computers beyond the users' control25.

1.6 Relationships with other eGovernment documents

Trials with standards and architectures for eGovernment have been underway for some years now in Germany and in other countries26. Experience from these trials and international exchange help make it easier to define and implement SAGA.

SAGA is published as part of the KBSt publication series which also includes, for example, the "V Model XT", the "Migrationsleitfaden" [Migration Guide] and the "DOMEA-Konzept" [DOMEA concept]. The documents of these series are adjusted to each other when updates are released. This means that SAGA supersedes contents and information of older documents and that new documents consider the contents and information of the latest SAGA version. A broad-based co-ordination process accompanies any SAGA update in order to avoid conflicts with valid documents.

E-Government-Handbuch [eGovernment manual]

In order to promote the Federal Government's eGovernment initiative – such as the BundOnline 2005 Initiative that was completed in 2005 – and to support federal-state and municipal agencies, the E-Government-Handbuch27 [eGovernment manual] is prepared under the leadership of the German Federal Office for Information Security. This manual is

25 The automatic installation of software playing certain music CDs is one negative example of non-requested saving of programs on computers.

26 Refer to the respective documents and publications in the UK [e-GIF], the United States of America [FIPS-PUBS], Australia [APEC] and Europe [IDABC].

27 Refer to http://www.bsi.bund.de/fachthem/egov/3.htm

14 SAGA 4.0

designed as a reference manual and central information exchange for issues related to eGovernment.

The E-Government-Handbuch [eGovernment manual] is a modular compilation of material that covers a broader range of issues and topics than SAGA. As far as identical issues are addressed, the E-Government-Handbuch [eGovernment manual] does so in a more concrete manner. This is why certain modules of the eGovernment manual are referenced from within SAGA28. SAGA sets forth guidelines, whilst the E-Government-Handbuch [eGovernment manual] explains the implementation of these guidelines and offers practical advice.

In mid-February 2003, SAGA became part of the E-Government-Handbuch [eGovernment manual]. It is the module of the manual with the strongest binding effect. All the other modules are designed to ensure conformity with SAGA.

When examining the focal issue of "IT and IT security", the study titled "Sichere Integration von E-Government-Anwendungen(SIGA)"29 [Secure integration of eGovernment applications] was drafted. The aim of this study is to adapt the technologies presented in SAGA for the business logic level, to identify correlations and to provide valuable, independent assistance for IT experts and decision makers.

IT-Grundschutz-Kataloge und -Standards [IT baseline protection catalogues and standards]

In order to draft IT security concepts for normal security requirements, BSI recommends standard security measures for typical IT systems in its IT-Grundschutz30 [IT baseline protection]. The aim of these IT-Grundschutz [IT baseline protection] requirements is – through the suitable application of standard security measures at organizational, manpower, infrastructure and technical levels – to achieve a security level for IT systems which is reasonable and sufficient for normal protection requirements and which can serve as a basis for IT systems and applications with high security requirements.

IT-Grundschutz [IT baseline protection] includes the BSI-Standards31 [BSI standards] for IT security management and the IT-Grundschutz-Kataloge32 [IT baseline protection catalogues] which replace the previous IT-Grundschutzhandbuch [IT Baseline Protection Manual]. The BSI-Standards [BSI standards] are broken down into:

a. BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS)33

[BSI standard 100-1: Management systems for Information Security],

b. BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise34

[BSI standard 100-2: IT baseline protection approach] and

28 Refer, for instance, to section 8.1.4 "Implementation of the security concept" on page 93 and section 8.5.4 "Technologies for authentication" on page 104

29 Refer to [SIGA] 30 Refer to http://www.it-grundschutz.de/ 31 Refer to http://www.bsi.de/literat/bsi_standard/32 Refer to http://www.bsi.de/gshb/deutsch/33 Refer to http://www.bsi.bund.de/literat/bsi_standard/standard_1001.pdf34 Refer to http://www.bsi.de/literat/bsi_standard/standard_1002.pdf

SAGA 4.0 15

c. BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz35

[BSI standard 100-3: Risk analysis on the basis of IT baseline protection].

The application of IT-Grundschutz [IT baseline protection] is supported in SAGA; the BSI-Standards [BSI standards] for IT security management and the IT-Grundschutz-Kataloge [IT baseline protection catalogues] are defined as mandatory standards36.

Barrierefreie Informationstechnik-Verordnung – BITV [barrier-free information technology ordinance]

The ordinance on the creation of barrier-free information technology pursuant to section 11 of Behindertengleichstellungsgesetz [law on equal opportunities for the disabled] (Barrierefreie Informationstechnik-Verordnung – BITV)37, which came into effect on 24 July 2002, is referenced in SAGA and is defined as a mandatory standard with regard to the implementation of the presentation and client layers38.

V-Modell XT

The V-Modell XT39 is the binding process model throughout the federal administration for the development of IT systems for the federal authorities. The V-Modell XT must be considered in strategic planning and project management efforts and in conjunction with the implementation of eGovernment applications.

Used as a guideline for planning and implementing development projects, this model defines the results to be achieved in a project whilst considering the entire system lifecycle. At the same time, it describes the concrete approach with which these results are to be achieved. Furthermore, the V-Modell XT also defines the responsibilities of each project participant. It hence serves as a basis for contracts, as a guideline for work and as a basis for communication.

The V-Modell XT is subject to ongoing upgrading in the form of releases.

IT Infrastructure Library – ITIL

When it comes to the efficient and reliable management of IT processes, the "IT Infrastruc­ture Library" (ITIL), as a process library which supplies best practices, has now become established as the globally accepted defacto standard. This is why KBSt has issued a series of publications concerning the application of ITIL40.

In ITIL, Service Management addresses a general-interest topic that must be considered from the beginning of the lifecycle of an IT application. This results in synergies for the approach according to the other standards which are presented in a KBSt study41.

35 Refer to http://www.bsi.de/literat/bsi_standard/standard_1003.pdf36 Refer to chapter 7 on page 79 and section 8.1 on page 9137 Refer to http://bundesrecht.juris.de/bitv/38 Refer to sections 4.5.3 on page 47 and 8.6.1 on page 10539 Refer to http://www.kbst.bund.de/v-modell40 Refer to http://www.kbst.bund.de/itil41 Refer to "ITIL und Standards für IT-Prozesse" [ITIL and Standards for IT Processes], version

1.0.1, KBSt Letter No. 1/2006, October 2006

16 SAGA 4.0

During the preparation of SAGA 4.0, an upgraded ITIL, version 3.0, was issued. In order to use a tried-and-tested approach as a basis and to be able to refer to German literature, ITIL version 2.0, which is supported by KBSt documents, is presented in the Engineering Viewpoint (chapter 7)42.

Migrationsleitfaden [Migration guide]

This guide43 is designed to offer both strategic/economic and detailed technical decision-making aids for forthcoming or recently completed migration projects. The focus of this guide is the replacement of proprietary products both with open source software (OSS) and – where necessary – future generations of proprietary products. Agency-specific scenarios are developed and different migration alternatives are discussed.

The Migrationsleitfaden [migration guide] was developed with a view to SAGA version 2.1 as far as relevant interfaces were concerned. SAGA updates will have no repercussions on the statements made.

DOMEA-Konzept [DOMEA concept]

DOMEA44 stands for "Dokumentenmanagement und elektronische Archivierung" [document management and electronic archiving] in IT-based workflows. The aim of this concept is to introduce the electronic file. Physical files are to be replaced with workflows at public agencies in the form of fully electronic, media-consistent procedures. The electronic file is subject to the same legal and functional requirements as conventional files. Since the publication of the concept in 1999, DOMEA has become an established standard for electronic workflows at federal, federal-state and municipal agencies. For product manufacturers, the DOMEA-Konzept [DOMEA concept] is a major source of information when it comes to identifying the demands of public administrations which are considered when products are developed further.

Besides the organizational concept and the resultant requirements catalogue, the modular concept includes further elements which address specific issues of the organizational concept in more detail.

The requirements catalogue of the DOMEA concept translates organizational requirements into functional requirements which are orientated towards the SAGA standards on the one hand whilst also influencing the updating process of the SAGA document on the other. The DOMEA concept describes the relevant requirements for software products related to the area of electronic workflow management. These requirements are in some respects even more demanding than SAGA and hence do not jeopardise SAGA conformity.

42 Refer to section 7.1 "IT Service Management with the ITIL" on page 7943 Refer to http://www.kbst.bund.de/migrationsleitfaden44 Refer to http://www.kbst.bund.de/domea

SAGA 4.0 17

1.7 The evolution processStandards and architectures in SAGA undergo a defined process before they are included:

a. Proposal for standards and architectures in the public discussion forum, via the contact form, from the SAGA expert group, the KoopA-SAGA project group, the central IT service providers from the federal administration or the SAGA authors

b. Examination of proposals by the SAGA authors

c. Discussion in the SAGA expert group on the standards and architectures which were found to be suitable by the SAGA authors

d. Acceptance of proposals in a KBSt resolution on the basis of the discussion between the SAGA authors and the SAGA expert group

e. Inclusion of the accepted standards and architectures in SAGA by the SAGA authors as soon as the resolution has been made by the KBSt

SAGA is updated at regular intervals, amended to reflect the latest developments and findings and published on the homepage of the KBSt45 and within the scope of the E-Government-Handbuch46 (eGovernment Manual).

If problems occur that cannot be resolved using known standards, requests for proposals (RFPs) are sent to the SAGA expert group in order to identify possible solutions.

Public discussion forum

A public forum at: http://www.kbst.bund.de/saga-forum enables Internet users to register and discuss issues related to the application and further development of SAGA. The results of the discussions are evaluated and, if suitable, are considered in the next version of the SAGA document.

Contact form

The SAGA homepage provides a contact form47 for SAGA users. This form can be used to send structured ideas and queries directly to the SAGA authors.

The SAGA expert group

The KBSt has established an expert group48 comprising representatives from business, science and administration and appoints the members. This expert group is involved in the updating process at regular intervals or whenever there is reason for involvement.

The KoopA-SAGA project group and central IT service providers of the federal administration

The Co-operation Committee for Automatic Data Processing for the Federal-government, Federal-state Government and Municipal Administration Sector (KoopA ADV) delegates

45 Refer to http://www.kbst.bund.de/saga46 Refer to http://www.bsi.bund.de/fachthem/egov/3.htm47 Refer to http://www.kbst.bund.de/saga-kontaktformular48 Refer to http://www.kbst.bund.de/saga-expertenkreis

18 SAGA 4.0

representatives from the federal states and municipalities to accompany the further development of SAGA in workshops. The SAGA authors draft a catalogue of questions for proposed amendments which are answered by the participants and supplemented by their own proposals. In analogy to this approach, the requirements of the central IT service providers of the federal administration are collected in workshops and written exchanges and taken into consideration in the updating of the document.

SAGA examination report

The proposals put to the SAGA authors in the public forum, via the contact form, in the SAGA expert group, in the KoopA-SAGA project group and by the central IT service providers of the federal administration are listed in a SAGA examination report49 and the result of the examination is documented. The reasons for acceptance or rejection are explained.

1.8 Structure of the documentChapter 2 addresses issues concerning the scope of validity and binding nature of SAGA. Furthermore, this chapter also presents minimum requirements concerning the openness of standards as well as definitions of the different classification of standards. In addition to this, the subject of SAGA compliance of eGovernment applications is dealt with.

Chapter 3 describes the architecture model for eGovernment applications. This model was also adopted for the description of eGovernment in Germany. Accordingly, the following chapters 4 to 8 present viewpoints of the architecture model on eGovernment in its totality.

a. Chapter 4 documents the goals of German eGovernment, the players, roles, frames of reference, guidelines and forms of interaction as well as the aims with regard to standardized processes (enterprise viewpoint).

b. Chapter 5 describes the activities for defining standardized data models and help for developers of data models (information viewpoint).

c. Chapter 6 contains a reference software architecture, which can be used to develop architectures for concrete eGovernment applications, and information for integrating modules, such as the one-for-all offerings (OFA offerings), into the software architecture (computational viewpoint).

d. Chapter 7 describes the IT Service Management and requirement of eGovernment computer centres for operating eGovernment applications, as well as the use of modules, such as OFA offers, in an existing infrastructure (engineering viewpoint).

e. Chapter 8 defines the standards, technologies and methods for the IT architecture and for ensuring data security (technology viewpoint).

Appendix A contains a list of references and Appendix B provides an alphabetic list of the standards referred to in chapter 8. Appendix C finally presents a list of the abbreviations used in SAGA.

49 Refer to http://www.kbst.bund.de/saga

SAGA 4.0 19

2 Fundamentals of SAGA

2.1 Scope of validity and binding effect of SAGA

Around 400 services have so far been identified for the different federal administrations. The services can be classified, for instance, according to their target groups50; refer to Fig. 2-1.

SAGA's scope of validity covers the federal administration and software systems with interfaces between federal authorities and federal-state and/or municipal authorities in order to support the services listed above.

SAGA includes recommendations concerning standards and architectures for eGovernment applications. The term "eGovernment applications" refers to software systems which are used to fulfil services of the Federal Government or which actively support the fulfilment of such services. In the case of systems with no direct interfaces with eGovernment, migration is recommended on condition of a positive outcome of the cost-to-benefit analysis. Whenever possible, the standard software51 to be bought should be primarily products or product versions which are compatible with SAGA recommendations. Furthermore, SAGA considers only those areas which have a major influence on the aforementioned objectives52 rather than all the elements of a technical architecture.

The Federal Ministry of the Interior recommends that SAGA be considered in invitations to tender for eGovernment applications for the federal administration in the manner described in section 2.4.1 "Definition of conformance" on page 25, and section 2.4.2 "SAGAconformance in invitations to tender" on page 26.

50 Refer to the section 4.6.2 on "Relationships in interaction" on page 49. 51 Software that is simply installed and configured 52 Refer to section 1.3 "Aims" on page 12.

Figure 2-1: Selected Federal Government services

G2C – Government to Citizen(Interaction between theadministration and citizens)

G2B – Government to Business(Interaction between theadministration and 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(Interaction between administrations)

• BA: Job exchange• DRV: Calculation and payment of

pensions• BMAS: Provision of information• DWD: Weather forecast and

meteorological advice• BpB: Provision of information and

order handling

• KBA: Central traffic and motor vehicle register

• BBR: Procurement for construction and civil engineering projects

• BMF: Management of Federal-Government properties

• BAköV: Further training and education

• BZR: Federal Central Criminal Register

20 SAGA 4.0

The federal ministries lay down rules for the binding effect of SAGA within their areas of competence.

2.2 Minimum requirements with regard to the openness of standards

One aim of SAGA is the use of open standards in eGovernment applications, refer to section 1.3 "Aims" on page 12. There are currently many different definitions for an "open standard", however, there is no one generally valid definition accepted by all. Various standardization committees have issued definitions which are essentially the same in terms of how a standard emerges, its documentation and application. However, opinions do differ when it comes to the type of standardization organization and the license cost system of a standard. These issues are rated differently by the various committees (e.g. IDABC, ETSI, DIN, CEN, ISO). SAGA is not designed as a forum for these discussions, instead it is to remain a practice-based recommendation. This is why "minimum requirements" were defined for the openness of standards which will also serve as an evaluation basis for accepting or rejecting a standard in SAGA.

The minimum requirements for the openness of standards for acceptance in SAGA are defined as follows:

a. The standard was published and documentation of standard specifications is either free or at most available against a nominal fee.

b. The intellectual property (for instance, in the form of patents) of a standard or of parts of a standard must, if possible, be accessible without being contingent upon the payment of a license fee.

c. The federal administration and the users of its services must be able to use the standard without restriction.

d. The standard must remain published and freely usable in the future.

2.3 Classification and life cycles of standards

2.3.1 Classification in SAGAStandards are divided into three categories. Competing standards which are not stated should not be used or only if absolutely inevitable; refer also to section 2.3.4 "Non-classifiedstandards" on page 25.

Under observation:

Standards are under observation if they are in line with the intended development trend, are finalized and meet the minimum requirements for the openness of standards53. These

53 Refer to section 2.2 "Minimum requirements with regard to the openness of standards" on

SAGA 4.0 21

standards may not yet have proven their worth in practical application or do not meet all the aims of SAGA; refer to section 1.3 "Aims" on page 12.

In the event that no competing mandatory or recommended standards exist in addition to the standards under observation, such standards under observation can be used in eGovernment applications. Only in justified exceptional cases should preference be given to standards under observation over higher classified alternatives.

Recommended:

Standards are recommended if they have been tried and tested in practical application but if a more suitable, mandatory standard exists or if they do not meet all the aims of SAGA. However, minimum requirements for the openness of standards must be fulfilled and investment security warranted.

In the event that no competing mandatory standards exist besides recommended standards, deviations from the recommended standards are permitted in justified, exceptional cases only.

Competing standards can be recommended parallel if they have clearly different fields of application. The standard which is best suited for the given application must be adopted in such cases.

Mandatory:

Standards are mandatory if they have been tried and tested in practical application and represent the preferred solution. They are established on the market and meet all the aims of SAGA. Such standards must be observed and applied with priority.

Competing standards can be mandatory parallel if they have clearly different fields of application. In such cases, the standard which is best suited for the given application must be used.

In the event that mandatory and recommended standards or standards under observation exist parallel, the latter - i.e. standards under observation - should only be adopted in justified, exceptional cases.

A standard classified as mandatory does not necessarily have to be used in every eGovernment application. A mandatory standard only should be adhered to if the use of the technology or functionality related to this standard is necessary or reasonable in view of the requirements of the specific application.

2.3.2 Extended classification of standardsThree lists for the extended classification of standards were introduced with the publication of SAGA 2.0 on the SAGA homepage at http://www.kbst.bund.de/saga-standards. No standards other than those on the Right of Continuance List (former Grey List) may be given preference over the standards classified in the SAGA document (mandatory, recommended,

page 20.

22 SAGA 4.0

under observation) – however, only if existing systems, in which these standards are already used, are being upgraded.

List of Suggestions

The List of Suggestions (former White List) was created in order to respond promptly to new developments and to be able to communicate these externally for information. During the course of developing the SAGA document further, the List of Suggestions is an important basis for including standards in SAGA.

Standards are listed in the List of Suggestions if proposals and ideas for their inclusion in SAGA were submitted to the SAGA authors, if they have potential for use in eGovernment applications and if these standards have not yet been classified further.

Standards in the List of Suggestions are evaluated by the SAGA authors and the SAGA expert group. The result of this evaluation can mean acceptance of the standards in the next version of the SAGA document, relocation to the Negative List (former Black List) or to the Right of Continuance List (former Grey List) or also remaining on the List of Suggestions, so that development can be observed, for instance, in the case of standards not yet finalized. Before being published in a new SAGA version, the standards on the List of Suggestions are again examined with regard to their suitability for inclusion.

Right of Continuance List

Standards are added to the Right of Continuance List (former Grey List) if they are no longer included in the current SAGA version, but if they had a "recommended" or "mandatory" status in an earlier SAGA version and/or if they were widely used in the market in the past. When existing systems are upgraded, these standards are to be kept in effect and can continue to be used. These standards, however, should no longer be used for new eGovernment applications.

Negative List

Within the scope of the SAGA discussion, certain standards that were already rejected in the past are repeatedly proposed for inclusion. The Negative List (former Black List) was set up in order to make the results of these discussions transparent and to identify those standards which can no longer be expected to be included in SAGA.

Standards are added to the Negative List if they were examined and rejected by both the SAGA authors and the SAGA expert group. The standards should not be used in new or existing eGovernment applications. Their use is only permitted if a parallel SAGA-compliant solution exists. Images, for instance, can be made available in BMP format even though this is on the Negative List, if images are also offered at the same time in a SAGA-compliant format such as GIF.

If a standard on the Negative List is developed further and differs from the old version in areas that were previously criticized, the version number of the negative-listed standard must be stated. Now nothing stands in the way of the new version being included in SAGA via the List of Suggestions (former White List).

SAGA 4.0 23

2.3.3 Life cycles of standardsBesides the standards classified in SAGA, refer to section 2.3.1 on page 20, other standards are recorded in three different lists, refer to section 2.3.2 on page 21. Whilst the classification of standards as "mandatory", "recommended" and "under observation" is defined and updated in the SAGA document, presentation and ongoing updating of the standards in the lists are carried out on the SAGA website at: http://www.kbst.bund.de/saga-standards.

Standards can pass through different stages during their life cycle. These are illustrated in Fig. 2-2 on page 24.

The transitions of a standard between the lists on the SAGA homepage at: http://www.kbst.bund.de/saga-standards and the classes in the SAGA document are defined in the following section.

1 New standards are proposed for classification by the SAGA authors, by experts or by users; refer to section 1.7 "The evolution process" on page 17. Without any further in-depth examination, these standards are initially compiled in the List of Suggestions. A thorough examination is carried out before a new SAGA version is created. Apart from the transfer to the SAGA document, to the Right of Continuance List or to the Negative List, the examination may also result in the standard remaining on the List of Suggestions. Such standards do not yet fulfil the requirements for inclusion in SAGA, e.g. because they are not yet finalized. Their inclusion is re-examined for the next SAGA version. Before completion of a new SAGA version, transitions 1 and 2 or 1 and 3 may also take place in one step.

2 Standards which, following examination, are not included in SAGA are added to the Negative List as rejected standards.

3 Standards are transferred from the List of Suggestions to the Right of Continuance List when thorough examination suggests that these standards should not be used in new projects, but can still be used in existing projects.

4 Following a positive examination of the respective requirements, refer to section 2.3.1 "Classification in SAGA" on page 20, standards are included in SAGA with the classification "under observation". If the respective requirements are fulfilled, the standard can also be directly allocated to one of the higher classes, i.e. "recommended" or "mandatory". The transitions 4 and 5, or 4, 5 and 6, respectively, are then carried out in one step.

5 Following successful examination of the respective requirements in SAGA, standards with "under observation" status are classified as "recommended" in SAGA. If the requirements are fulfilled, the standard can also be directly allocated to the higher class, i.e. "mandatory". Transitions 5 and 6 are then carried out in a single step. Standards which after examination still fail to meet the requirements for higher classification in SAGA and which are not be transferred to the Negative List retain the "under observation" classification.

24 SAGA 4.0

6 Following successful examination of the respective requirements in SAGA, standards with "recommended" status are classified as "mandatory". Standards which after examination still fail to meet the requirements for higher classification in SAGA and which are not be transferred to the Right of Continuance List retain the "recommended" classification.

7 Following examination and the respective re-evaluation in SAGA, standards with "mandatory" status are classified as "recommended". A standard which should no longer be used in new projects can also be directly transferred to the Right of Continuance List. Transitions 7 and 8 are then carried out in a single step. Standards which, after examination, continue to meet the requirements for classification as "mandatory" maintain their status.

8 If, after in-depth examination, standards with a "recommended" status should not be used any longer in new projects, these standards are transferred to the Right of Continuance List.

9 Obsolete standards in the Right of Continuance List which were kept sufficiently long in the Right of Continuance and which should not be maintained any longer are transferred to the Negative List.

10 Standards with "under observation" status which no longer have any chance of ever being transferred into a higher classification are directly transferred to the Negative List.

The standards which are examined within the scope of preparing a new SAGA version can not only move one step along the lifecycle previously presented, they can also retain their status or pass through several steps in one go.

Figure 2-2: Lifecycles of SAGA standards

New standards

Negative List(former Black List)

SAGA DOCUMENT SAGA HOMEPAGE

Under observation

Mandatory

Right of Continuance List (former Grey List)

List of Suggestions(former White List)

Recommended

6 7

5

4

8

10 9

3 2

1

SAGA 4.0 25

2.3.4 Non-classified standardsStandards or architectures not listed in SAGA:

a. are not specific for eGovernment or eCommerce applications,

b. refer to a detail level other than that of the standards dealt with here in SAGA,

c. are included in or referenced by the aforementioned standards,

d. are too new or too controversial and are hence unlikely to become a standard in the near future,

e. are not desired because they are in conflict with standards or architectures already introduced or because they restrict interoperability.

2.4 SAGA conformance

2.4.1 Definition of conformanceThe SAGA conformance of an eGovernment application54 is evaluated on the basis of the models, procedures and standards described in SAGA:

a. Consideration of standardized process models

b. Consideration of standardized data models

c. Compliance with the standards and architectures described in SAGA

d. Use of existing one-for-all offers (OFA offers)55

In order to be able to make a comprehensive statement concerning the SAGA conformance of an eGovernment application – especially in conjunction with the implementation of complex, specialized processes – an application should first be broken down into individual units56 before evaluating its conformance. Software units developed internally are distinguished here from units (products) developed externally. In order to evaluate the SAGA conformance of products, importance is primarily attached to communication interfaces, data interchange formats and security. In the case of in-house developments, the technologies for creating models and implementing the application are additionally relevant as is the use of OFA offers.

The SAGA homepage provides a blank declaration of conformance and an example of a completed declaration of conformance with checklists for software units and external units57. The checklists feature topical areas which are relevant for in-house developments or for products, respectively.

54 The term "eGovernment application" is used as a general term for any IT system which provides eGovernment services of the Federal Government. With regard to the definition of the term "eGovernment service", please refer to section 4.1.2 "The term "service" ineGovernment" on page 35.

55 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76. 56 According to the XT process model, a unit is the system element on the very top of a

hierarchical structure; refer to http://www.v-modell-xt.de/57 Refer to http://www.kbst.bund.de/saga-konformitaet

26 SAGA 4.0

Which specific standards from the relevant topical areas have to be used to ensure SAGA conformance varies depending on the area of application and the functional scope of the application. For instance, definitions for creating information services for mobile phones and/or PDAs are only relevant for SAGA conformance if these terminal devices are to be used by the eGovernment application. SAGA conformance is hence achieved by applying the particular subset of all SAGA standards which is relevant for the specific eGovernment application.

2.4.2 SAGA conformance in invitations to tender

In order to avoid neglecting the customer's concrete requirements when it comes to SAGA conformance and in order to avoid having to exclusively rely on statements by the supplier, the customer should include a section on "SAGA conformance" and SAGA-relevant criteria in its contracting documents.

A general demand for SAGA conformance is not enough in order to achieve the goals of SAGA. Due to the complexity of the document, a general demand leaves too much room for interpretation and misunderstanding. This makes it difficult for the supplier to fulfil the requirements and for the customer to check that requirements are fulfilled.

This is why no general demand for SAGA conformance may be made.

Instead, the declaration-of-conformance process described below should be applied by the customer and the supplier, refer to Fig. 2-4. This process limits the room for interpretation and reduces misunderstandings. The concrete demands can be checked and thus create a sound basis for the contract between the customer and the supplier. Specifying the concrete details of demands also prevents offers from becoming unnecessarily expensive.

Figure 2-3: Layout of the SAGA declaration of conformity and checklists

eGovernment application

SW unit 1(In-house

development)

External unit 1(product)

Unit n(...)

...

Check-list for SW units developed

in-house

Check-list forexternal units

(products)

Check-list for...

...

SAGA 4.0 27

The process essentially comprises five steps which are briefly described below.

Step 1: Including aspects of SAGA conformance aspects in the contract documents of an invitation to tender

The customer puts together a series of exclusion and evaluation criteria which cover all the relevant aspects of the desired application. The criteria group example which can be downloaded from the SAGA homepage can serve as a template58. This criteria group example contains possible criteria which can result from the application of SAGA. The customer must select or supplement the criteria which are relevant for the project. The criteria group example contains explanatory information which makes selection easier.

The customer must also decide whether criteria are defined as exclusion criteria or as evaluation criteria. Exclusion criteria should be used very moderately because they reduce the number of bids. Alternatively, high-weighted evaluation criteria should be taken into consideration.

Step 2: Supplier response to the SAGA conformance criteria group within the scope of offer preparation

The supplier responds to the "SAGA conformance" criteria group within the scope of his offer preparation. He can base his offer on a completed criteria group example which can also be downloaded from the SAGA homepage59. This criteria group is filled in, it serves as

58 Refer to http://www.kbst.bund.de/saga-konformitaet59 Refer to http://www.kbst.bund.de/saga-konformitaet

Figure 2-4: Declaration-of-conformance process

SUPPLIER

Create contractingdocuments

with criteria related to SAGA

Evaluate offerconsidering supplier repliesconcerning SAGA criteria

Project started

Project completed

Send documents

Send offer

Award contract

Hand over application

CUSTOMER

Write offerincluding replies concerning

customer criteria related to SAGA

Implement joband subsequently complete SAGA

conformance declarationPerform acceptance

and check SAGA conformance

1

3

5

2

4

28 SAGA 4.0

an example and contains explanatory comments which are helpful when filling in a concrete criteria group.

Step 3: Supplier examination of the details concerning SAGA conformance, evaluation of the respective criteria within the scope of offer evaluation

The customer checks the criteria groups completed for the offers received. Offers which do not fulfil the customer's requirements for the "SAGA conformance" criteria group, i.e. which cannot warrant "SAGA conformance", are evaluated accordingly.

Step 4: Supplier completion of the declaration of conformance for the completed application

If the supplier has implemented the eGovernment application, he declares the SAGA conformance of the application in writing. To do so, he completes the declaration of conformance for the application and attaches the checklists for the individual units of the application. Deviations from the commitments made in the completed "SAGA conformance" criteria group should be discussed with the customer at an early point in time and the reasons for such deviations must be stated in the declaration of conformance. The supplier can be supported by the sample declaration of conformance that can be downloaded from the SAGA homepage60. Blank templates of a declaration of conformance are also available on this homepage.

Step 5: Examining SAGA conformance on the basis of the offer and the declaration of conformance by the supplier within the scope of acceptance

During acceptance, the customer can evaluate SAGA conformance on the basis of the "SAGA conformance" criteria group completed by the supplier in the offer and the declaration of conformance issued after implementation. This evaluation is as easy as possible thanks to the specific details of the offer. If the application deviates from the commitments made in the offer, this is deemed to be a defect which must be considered during acceptance.

2.4.3 SAGA conformance despite low classificationA SAGA-conformant application must not necessarily have been implemented solely with technologies which were given a "mandatory" classification in SAGA. For various reasons, the use of standards with a lower classification (or even without a classification in SAGA) is possible without violating SAGA conformance61.

A lack of alternatives

The use of recommended standards is SAGA conformant if no mandatory alternatives exist. Standards "under observation" can also be used and are SAGA conformant if no mandatory or recommended standards are listed in SAGA for the respective application purpose.

60 Refer to http://www.kbst.bund.de/saga-konformitaet61 Refer also to the definitions for classification and lists on the web in section 2.3 on page 20

SAGA 4.0 29

Special functions and application areas

If, for an area of application, SAGA not only contains higher classified standards ("mandatory" or "recommended") but also lists standards with a lower classification ("recommended" or "under observation"), the user must refer to the description of the standards in order to find out the circumstances under which the lower classified standards can be given preference. The reasons for this are, first and foremost, when extended functionality62 is required, or special areas of application63. The use of standards "under observation" should be particularly well considered because no investment security has been established for these standards and because it is not warranted that they will remain in effect. With the next version of SAGA, such standards can already be featured on the Negative List (former Black List).

Parallel offers

If SAGA-conformant standards are used as depicted above, additional standards and/or formats can be used which are not listed in SAGA or which have a lower classification in SAGA. If, for example, spreadsheet data64 is made available in CSV format, the same data can be additionally made available in other formats, such as Microsoft Excel, without violating SAGA conformance.

Use of external units (products)

In the case of external units (in contrast to software units developed in-house), the focus is placed on communication interfaces, data interchange formats and security. Technologies for process modelling, data modelling, application architecture and the use of OFA offers65 do not form part of the checklists for the SAGA declaration of conformance. In the case of certain units, customers should check whether the corresponding technologies should be specified in order to make use, for instance, of existing infrastructures for operating the unit and to achieve synergies with other eGovernment applications.

Technologies beyond the focus of SAGA

Of course, topics for which SAGA does not make or has not yet made any statements have no effect on the evaluation of the SAGA conformance of an eGovernment application.

2.4.4 Responsibility for conformance

The public agency responsible for an eGovernment application is also responsible for ensuring conformance with SAGA. The public agencies are also responsible for examining ways to migrate special applications.

The federal ministries lay down rules for responsibility within their areas of competence.

62 Refer, for instance, to the descriptions for the different PDF versions in section 8.6.7.1 on page 109

63 Refer, for instance, to the descriptions of Unicode coding in section 8.6.2 "Character sets" on page 106

64 Refer to section 8.6.7.4 "Formats for spreadsheets for further processing" on page 11265 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76

30 SAGA 4.0

Due to the complexity of SAGA, the process of securing SAGA conformance is also complex. This is why efforts are being made to provide even better support for users in future. Information on the latest developments in this field can be found on the SAGA homepage66

of the Federal Ministry of the Interior.

2.4.5 Migration for conformance

Transition phase

SAGA is undergoing continuous development and regular updating so that it can be adapted to meet new requirements. This is why individual eGovernment applications, which are orientated towards an older SAGA version67 , may temporarily not comply with the current SAGA version.

Migration plans should be developed for non-conformant applications if the result of the cost-to-benefit analysis is positive. This may only be the case where major enhancements of the application are concerned.

Measures to achieve conformance

The following measures are designed to support conformance with SAGA:

a. SAGA is included in project planning processes at an early stage.

b. Conformance with SAGA is specified and checked when projects are approved.

c. Conformance with SAGA can be a mandatory criterion for projects subsidized by public administrations.

d. SAGA conformance is specified as a mandatory criterion for government contracts.

2.4.6 Non-conformanceeGovernment applications which are, as a whole or in part, non-conformant with SAGA are subject to the following restrictions:

a. The use of one-for-all offers (OFA offers)68 can be restricted.

b. Advisory and consultancy services by competence centres are limited or even impossible.

c. Interfaces with such systems may under certain circumstances not be supported.

d. Generally speaking, no subsidies are available from public administrations.

66 Refer to http://www.kbst.bund.de/saga-konformitaet67 Old SAGA versions are available from the SAGA archive at: http://www.kbst.bund.de/saga68 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76.

SAGA 4.0 31

3 Architecture model for eGovernment applications

3.1 OverviewWith the architecture model, SAGA aims at the following:

a. In an effort to facilitate communications, a common understanding of up-to-date IT architectures, IT technologies and eGovernment structures is to be achieved.

b. IT technologies available for eGovernment applications are to be identified, compared, evaluated with regard to their relevance, and given a uniform and consistent structure using this model.

c. The aim is to provide uniform standards that can be used when it comes to implementing eGovernment projects.

The Reference Model for Open Distributed Processing (RM-ODP69), which was standardized as ISO/IEC 10746-3:1996, is the approach of choice for describing complex, distributed eGovernment applications. The discussion on the application is broken down into different viewpoints in order to reduce the complexity of the overall architecture and this in turn makes it easier to understand and master an application. The object-orientated paradigm70 is the basis for the RM-ODP. Object orientation promotes clear-cut structures, re-usability and updating capability of both the models created and the system.

The RM-ODP model defines five viewpoints of a system refer to Fig. 3-1:

a. The enterprise viewpoint specifies the purpose, use area and rules of an application.

b. The information viewpoint describes the structure and semantics of the data to be processed, i.e. the data model.

c. The computational viewpoint represents the breaking down of an application into functional elements and their interaction interfaces.

d. The engineering viewpoint represents the distribution of the individual elements of the system to physical resources and their connections.

e. The technology viewpoint describes the technologies used to implement the system.

The five viewpoints can be used both to describe existing systems and to model new systems and applications. SAGA suggests, but does not dictate, the use of RM-ODP to describe eGovernment applications.

69 Reference Model of Open Distributed Processing, refer to [ISO 1996]70 Refer to [KBSt 2007], section 3.3.1

32 SAGA 4.0

Furthermore, the SAGA document itself is structured according to the RM-ODP model. The result are chapters which can each be assigned to a viewpoint; refer to section 1.8 "Structureof the document" on page 18.

3.2 Enterprise viewpointThe 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"

Figure 3-1: Viewpoints according to RM-ODP

eGovernment

Hardware and infrastructure

Standards andtechnologies

Data structureand semantics

System elementsand interfaces

Purpose, use areaand rules

Enterprise Viewpoint

Engineering Viewpoint

Technology Viewpoint

Information Viewpoint

ComputationalViewpoint

SAGA 4.0 33

(citizen, business, other public agency, etc.) to the rendering of the service. On their first stage of development, these process models should be left at a relatively abstract level.

New proposals for process definitions should always be checked with a view to

a. Re-usability

b. Simplicity

c. The possibility to be described by existing process definitions.

The KBSt website provides a guideline for process and data modelling71 and supports those in charge during process modelling. Support is also available from the "Workflow Management, Processes and Organization" (WMPO CC) competence centre72 at the Federal Office for Information Technology (BIT).

Chapter 4 "Enterprise viewpoint: Fundamentals of eGovernment" on page 35 describes the enterprise viewpoint of German eGovernment as a model. In section 8.2 "Process models" on page 95, SAGA provides the descriptive tools needed for the definition of the enterprise viewpoint for concrete eGovernment applications.

3.3 Information viewpointThis viewpoint determines the structure and semantics of the system's information. Furthermore, the activities (status changes) which can be carried out with the information objects are also defined along with the restrictions which apply to these activities.

A stringent process definition calls for the use of general data definitions for major data identities (such as the application) and for the data to be exchanged between processes or applications.

Data models should always be checked with a view to

a. Re-usability

b. Simplicity

c. The possibility to be described by existing data models

The KBSt website provides a guideline for process and data modelling73 and supports those in charge during data modelling.

Chapter 5 "Information viewpoint: Standardization of data models" on page 55 corresponds to the information viewpoint of German eGovernment and should be considered when creating own data models. Section 8.3 "Data models" on page 96 classifies the technologies to be applied.

71 Refer to http://www.kbst.bund.de/modellierungsleitfaden72 Refer to http://www.kbst.bund.de/, "E-Government" > "Vorgangsbearbeitung, Prozesse und

Organization" 73 Refer to http://www.kbst.bund.de/modellierungsleitfaden

34 SAGA 4.0

3.4 Computational viewpointThis viewpoint breaks an application down into logic, functional elements which are suitable for distribution. The result is objects with interfaces via which they offer their functionality and/or use the functionalities of other objects.

Interaction takes place in the form of local and remote communication between the elements. Secure interaction may be required here. The protection aims are described in section 8.1.2.1 "Protection aims" on page 92.

The applications are also broken down into layers in which each of the individual elements can be found.

Chapter 6 "Computational viewpoint: Reference software architecture" on page 65 provides a description of a general computational viewpoint of eGovernment applications which can be used as a basis for creating this viewpoint for a concrete online service. Furthermore, the chapter also describes the architectures of different cases of eGovernment applications, such as systems and services. In chapter 8 "Technology viewpoint: Standardsfor IT architecture and data security" on page 91, SAGA defines standards and technologies for implementing the computational viewpoint and for creating secure interaction between system elements.

3.5 Engineering viewpointThe engineering viewpoint describes the system support needed to permit the distribution of objects from the computational viewpoint. This includes system elements for executing objects, such as computer hardware and communication infrastructures, as well as all kinds of software platforms for distributed systems.

Chapter 7 "Engineering viewpoint: IT service management and reference infrastructure" on page 79 gives a general description of the engineering viewpoint for eGovernment applications of federal agencies. The corresponding viewpoint of a concrete online service can be derived from this. Chapter 8 "Technology viewpoint: Standards for IT architectureand data security" on page 91 presents several technologies to be adopted in order to support network security.

3.6 Technology viewpointThis viewpoint describes the concrete technologies selected for implementing the system.

In chapter 8 on page 91, SAGA describes the classified standards, technologies and methods for the IT architecture and data security.

SAGA 4.0 35

4 Enterprise viewpoint: Fundamentals of eGovernment

In line with the definition of the enterprise viewpoint in chapter 3 "Architecture model foreGovernment applications", the fundamentals of eGovernment in Germany will be described in the following as the overall environment for the standardized introduction of eGovernment applications.

Besides this general approach, the process level in eGovernment will also be addressed in more detail. The process models are the starting point for deriving inter-agency modules which are to be integrated into eGovernment applications.

4.1 Definitions of eGovernment in Germany

4.1.1 The term "eGovernment"eGovernment (electronic Government) is understood to be the use of electronic information and communication technologies in order to involve customers of administrations in the activities of government and the public administration74. The aim is to offer customers of administration services, i.e. citizens, businesses and the administration itself, electronic access to administration services and information. The possibilities offered by these technologies are very diverse. They range from the modernization of administrative processes using electronic workflow management to the provision of administrative information using public agency portals on the Internet and to complex transactions and interactive electronic web services for citizens.

Aspects of eDemocracy are not explicitly addressed in this context because the government is assumed to pursue different approaches towards its roles in relation to citizens and business. As far as eGovernment is concerned, citizens and business are the clients of administrations and governments. eDemocracy is based on the concept of the citizen as the sovereign, representing the basis for the government to exert its power.

4.1.2 The term "service" in eGovernmentWithin the scope of eGovernment, the term "service" is understood to be the execution or result of an activity by a public administration which serves the citizen, business or another public agency75. A service includes processes, obligations and burdens, such as the recognition as a conscientious objector, applications for unemployment benefits, or the granting of an import permit.

74 Refer to BSI: "eGovernment Glossary", version dated 4 January 2006, section 1.1, page 3; http:// www.bsi.bund.de/fachthem/egov/download/6_EGloss.pdf

75 Refer to BSI: "eGovernment Glossary", version dated 4 January 2006, section 1.2, page 4; http:// www.bsi.bund.de/fachthem/egov/download/6_EGloss.pdf

36 SAGA 4.0

4.2 The philosophy underlying eGovernment

eGovernment opens up new ways for reform and innovation in the pubic administration using electronic services and processes. This concerns internal relationships within administrations on the one hand as well as external relations between administrations, citizens and business on the other76.

4.2.1 Orientation towards the needs of citizensThe Internet and networked computer systems are shaping the future. The growing penetration of the Internet, especially in private households, is also leading to a growing demand for electronic services by government. eGovernment is the response to this demand.

For citizens, contact with administrations sometimes involves long distances and waiting time. Compared to this, Internet-based communication and transactions can help save considerable amounts of both time and money. This means that in future many citizens will frequently be able to handle their administration matters from the comfort of their own homes. Internet portals simplify access to public information and services.

In order to tailor the service offered by administrations to demand, citizens must remain free to choose which form of access to the administration they wish to use. Access to the public administration must continue to be possible, in person, via the Internet and e-mail. These access channels must be integrated into administrations as early and as far as possible and processed in a standardized manner so that administration work can be shaped as efficiently as possible. Moreover, Internet barriers and restrictions posed by the Internet must be reduced and/or avoided.

4.2.2 eGovernment as a location factor for businessCompanies maintain regular contacts with the public administration in many different fields, e.g. for certification, licensing and approval procedures, as well as procedures related to the customs and excise and tax administration.

On a global scale, all leading industrialized nations introduced powerful eGovernment services in recent years. eGovernment is today a location factor. The national and EU plans for expanding eGovernment services in the years to come are hence fully orientated towards boosting benefits for citizens and especially for companies, as well as reducing the cost of administration services. In some federal states, the focus is being placed on the demand-based expansion of eGovernment services and on increasing the number of users. The beginning integration of administration and business processes along value chains makes it possible to reduce bureaucracy costs in the interest of business and government, e.g. in the field of statistics or the import and export of goods.

76 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter I, module "Chefsache E-Government – Leitfaden für Behördenleiter" [eGovernment as an executive task – a guide for heads of public administrations]

SAGA 4.0 37

The availability and quality of electronic administration services is hence a factor not to be underestimated in the global competition to entice companies to relocate or set up business. Boundary conditions must be attractive and barriers for companies must be kept as low as possible.

4.3 Strategic goalsThe philosophy addressed in the previous section forms the main objective for the strategic goals of eGovernment for Europe and Germany. In order to reach these goals, the public administration must be modernized. A general overview of the programmes, strategies and measures pursued by the Federal Government here with a focus on human resources, administration management, organization and eGovernment can be found at http://www.verwaltung-innovativ.de/. The following section presents the Federal Government's central programmes and strategies which, in the years to come, will pave the way for the further development of eGovernment on Federal, federal-state and municipal level in Germany.

4.3.1 eGovernment 2.0 – A Federal Government programme

The top priority of the eGovernment 2.0 programme77, which was adopted by the Federal Cabinet in September 2006, is to make the federal administration fit for a service-orientated information society. The needs of users of eGovernment applications are to be focused on more in the future – for instance, users are to be enabled to communicate with public agencies without the fear of identity fraud or electronic annoyance78. Accordingly, the federal administration's Internet offering is to be expanded by 2010, both in terms of quality and quantity. The programme is being coordinated by the Federal Ministry of the Interior in cooperation with the different federal ministries.

The goals listed are supported by measures in four fields of action:

a. PortfolioDemand-orientated, quality and quantity-related expansion of the eGovernment offering by the Federal Government (e.g. Arbeitsagentur-Online [online job agency]79)

b. Process chainsMedia-consistent electronic process handling between business and the administration using integrated process chains, as well as standards for interface and exchange formats (e.g. secure foodstuff chain80)

77 Refer to http://www.kbst.bund.de/e-government/78 National Plan for Information Infrastructure Protection (NPSI): Federal Ministry of the

Interior, 2005; http://www.bmi.bund.de/, navigation topics "Themen A-Z" [A-Z topics] > "Informationsgesellschaft" [Information society] > "Sicherheit in der Informationstechnik" [Security in information technology] > box: "Links zum Thema" [Links to the topic]

79 Refer to http://www.arbeitsagentur.de/80 IT FoodTrace research project: http://www.itfoodtrace.de/

38 SAGA 4.0

c. IdentificationLaunch of electronic identity management using future functions and applications, e.g. on the electronic ID card (ePA)81 as well as the development of eIdentity strategies

d. CommunicationA secure communication infrastructure in the form of portals for citizens, businesses and administrations (e.g. citizens' portals82)

4.3.2 Deutschland-Online - The joint eGovernment strategy of the Federal Government, federal-state governments and municipalities.

The aim of Deutschland-Online (DOL)83 is to create a fully integrated eGovernment landscape in Germany, so that electronically captured data can be exchanged between the administrations of the Federal Government, federal states and municipalities in a consistent manner and across all levels. This strategy is based on the following principles:

a. One For All (OFA)The individual participants from Federal Government, the federal states and municipalities develop model solutions which are used by the other participants.

b. Responsibility of lead unitsThe main responsibility for a DOL project lies in the hands of the proposing public agency which is also in charge of the creation of a tenable business model and its implementation.

c. Transparency of standards – competition between products.Transparent standards and process models are used to define a framework for which various products can be selected, hence promoting interoperability between different products.

In order to implement the strategic goals, the heads of federal and federal-state government adopted the Deutschland-Online action plan in June 2006 with six prioritized projects and extended this in June 2007 with the IT implementation of the EU services directive84:

Infrastructure85

The Federal Government, federal states and municipalities currently have different network infrastructures wich are not connected to each other and hence constitute island solutions. This means that for a host of public agencies it is not always possible to exchange data with other agencies in a reliable, simple and secure manner. The establishment of a

81 Refer to http://www.epass.de/82 Refer to http://www.kbst.bund.de/e-government/, navigation item: "Bürgerportale"

[Citizens' portals] 83 Refer to http://www.deutschland-online.de/84 Refer to http://www.deutschland-online.de/, navigation item "Strategie" [Strategy] >

download: "Aktionsplan Deutschland-Online vom 14.06.2007.pdf" [Deutschland Online action plan dated 14 June 2007]

85 Refer to http://www.deutschland-online.de/, navigation item "Vorhaben" [Projects] > "Priorisierte Vorhaben" [Prioritized projects] > "Infrastruktur" [Infrastructure]

SAGA 4.0 39

communication infrastructure for Germany's public administration is designed to create a uniform network and hence achieve secure electronic communications between public agencies on Federal, federal-state and municipal level.

Standardization

The purpose of the DOL "Standardisierung" [Standardization] project is to support and coordinate the development and provision of technical standards for electronic data interchange (XÖV standards), so that electronic administration processes can be implemented in an efficient and uniform manner. For this purpose, the project for supporting the XÖV projects offers public administrations coordinated and harmonized measures, such as development methods, standardized data models, tools and technical infrastructures, along with advisory services and PR work.86

IT implementation of the EU services directive87

The goal of the project is to simplify and accelerate electronic administration processes in Germany within the scope of the EU services directive88. As of the end of 2009, entrepreneurs in the European Union are to be able to launch and perform their service activities via a uniform online contact, irrespective of their nationality or of the member state in which they are currently located. By mid-2008, a model for the IT implementation of the directive will be developed and tested as a milestone on the road towards this goal. Within the scope of this model, the infrastructural requirements at national level are to be defined, the IT support required for media-consistent process handling is to be described, a suitable IT architecture developed and technologies proposed with a view to the interfaces required.

Registration services89

The registration data of 82 million citizens in Germany is currently electronically captured, registered and managed in a distributed manner at more than 5,000 registration offices and used in approx. 114 million business transactions every year – for instance to provide information. As of 1 September 2006, the Federal Government was given the sole legislative competence of registration services as part of federalism reform. The aim is to create a Federal Identity Register (BMR) in addition to the municipal register in order to simplify registration procedures for citizens, to make use of the identity register more efficient and less expensive for businesses and administration, to improve the quality and up-to-dateness of the registration data and to make it possible to create nationwide, uniform online services.

86 For more details, refer to section 5.3 "The Deutschland-Online "Standardization" project" on page 59 and http://www.deutschland-online.de/, navigation items "Vorhaben" [Projects] > "Priorisierte Vorhaben" [Prioritized projects] > "Standardisierung" [Standardization]

87 Refer to http://www.deutschland-online.de/, navigation item "Strategie" [Strategy] > download: "Aktionsplan Deutschland-Online vom 14.06.2007.pdf" [Deutschland Online action plan dated 14 June 2007]

88 Refer to section 4.5.4 "EU services directive – Creating a single EU market" on page 4889 Refer to http://www.deutschland-online.de/, navigation item "Vorhaben" [Projects] >

"Priorisierte Vorhaben" [Prioritized projects] > "Meldewesen" [Registration services]

40 SAGA 4.0

Motor vehicle registration services90

Citizens and the business sector can currently perform certain tasks in conjunction with the registration, de-registration and re-registration of motor vehicles online (e.g.: entering vehicle data to prepare for registration, reserving custom registration numbers). Citizens, however, still have to carry out the actual procedure itself on site at the registration offices. The aim of the project is to find an organizational, legal and technical solution for vehicle registration which offers citizens and the business sector a consistent process via the Internet without media inconsistencies.

Civil status registration services91

On 23 February 2007, the "Gesetz zur Reform des Personenstandsrechts (PStRG)" [Law Reforming Civil Status Law] was ratified permitting, as of 1 January 2009, electronic registers and making these, as of 1 January 2014, mandatory. The aim of the project is to develop an electronic procedure for civil status registration services based on the Law and to use this to implement pilot projects for civil status registration services in certain federal states and also to enable citizens to obtain register information and apply for documents online. Part of the project also involves automated communications between the civil status register and other public agencies in response to requests for information. This exchange is to support the "XPersonenstand" data format to be developed.

Other Deutschland-Online projects

In addition to the previously described projects, there are a number of other projects being implemented within the scope of Deutschland-Online92:

a. Official statistics

b. BAföG (Federal Education Assistance Act)

c. Clearing houses

d. German Forum for Electronic Signatures and Chip Cards

e. Geodata

f. Business models

g. Commercial register

h. Judicial register

i. VEMAGS (Procedure management for bulk and heavy transports)

j. Internet portals / Responsibility finder project

k. XAusländer [XForeigners]

90 Refer to http://www.deutschland-online.de/, navigation item "Vorhaben" [Projects] > "Priorisierte Vorhaben" [Prioritized projects] > "Kfz-Wesen" [Motor vehicle registration services]

91 Refer to http://www.deutschland-online.de/, navigation item "Vorhaben" [Projects] > "Priorisierte Vorhaben" [Prioritized projects] > "Personenstandswesen" [Civil status registration services]

92 Refer to http://www.deutschland-online.de/, navigation item "Vorhaben" [Projects] > "Weitere Vorhaben" [Other projects]

SAGA 4.0 41

l. XSozial [XSocial]

4.4 Organizational requirementsThe implementation of eGovernment in Germany is bound by organizational requirements which must be taken into consideration. The most important of these requirements are described in the following.

4.4.1 Cross-administration interaction

Federalism in Germany

When implementing eGovernment, federalist states like Germany must face the problems of a de-centralized administration structure because the de-centralized administrative units are largely independent of central government.

Whilst the Federal Government holds most of the legislative power, it is the federal states and municipalities that are mainly responsible for implementation. The direct federal administration performs national tasks. Only those functions specifically defined in the Grundgesetz93 [German Basic Law] (articles 87-89) have an underlying administrative structure of their own, such as the Foreign Service, the Federal Armed Forces, the Federal Police or the Federal Revenue Administration. Besides these functions, there are other national tasks which are typically performed by special administrative agencies without an underlying administrative structure of their own (e.g. the Federal Criminal Police Office, the Federal Statistics Office, the German Patent and Trade Mark Office).

The immediate federal administration consists of:

a. The supreme federal authorities, e.g. the federal ministries, the Office of the Federal President and the Press and Information Office of the Federal Government

b. The superior federal authorities with central responsibility for a particular aspect for the entire Federal Republic of Germany (for example, the German Federal Cartel Office)

c. The intermediate-level federal authorities with regional responsibility (e.g. the different regional tax offices)

d. The lower-level federal authorities with locally restricted activities (for example, main customs and excise offices)

Within the scope of certain federal-state tasks related to law enforcement, the Federal Government commissions external administrative bodies as independent legal entities. These legal entities, in their capacity as corporate bodies, institutions and foundations of the indirect federal administration, are independently responsible for their fields of competence throughout the territory the Federal Republic of Germany and report to a ministry.

Comparable structures exist in the individual federal states. Furthermore, cities, districts and municipalities constitute the third administrative level in their capacity as territorial

93 Basic Law of the Federal Republic of Germany [German Constitution] (GG): http://www.gesetze-im-internet.de/bundesrecht/gg/

42 SAGA 4.0

communities with autonomous administrations which also perform their own tasks in addition to federal and federal-state functions.

The users of eGovernment services usually do not differentiate between the federal, federal-state and municipal levels of administration. Instead, companies and citizens tend to expect standardized and consistent eGovernment services, refer to Fig. 4-1.

What is generally needed is cooperation, networking and coordination within and between administrative levels. A first step taken at federal level was the implementation of the Informationsverbund Berlin-Bonn (IVBB)94 [Information Network Berlin-Bonn] which is an intranet for the supreme federal authorities. The upgrading of this network to form the Informationsverbund der Bundesverwaltung (IVBV)95 [Federal Administration Information Network] will connect all the federal authorities to a secure, closed network – this constitutes an enormous challenge on both a technical and organizational level96.

With Deutschland-Online as the joint national eGovernment strategy of the Federal Government, the federal states and municipalities, an expanded action plan was presented in June 200797.

94 Refer to http://www.kbst.bund.de/ivbb95 Refer to http://www.kbst.bund.de/ivbv96 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter V, sub-

chapter C, module: "Network platform for eGovernment" 97 Refer to section 4.3.2 "Deutschland-Online - The joint eGovernment strategy of the Federal

Government, federal-state governments and municipalities." on page 38

Figure 4-1: eGovernment interaction in Germany

MunicipalitiesFed. Gov.

Agency

CitizensCitizensCitizens

Fed. States

Agency Agency Agency

Agency

G2G

G2C

Business€

G2B

Business€

Business€€

G2B

G2G

G2G G2G

G2G

§§

§§

§§ §

§§

SAGA 4.0 43

Germany as a member of the European Union

As a member of the European Union (EU), the Federal Republic of Germany is increasingly being required to implement cross-border eGovernment services like those demanded in the EU services directive. The goal is to create a uniform, single market in the EU and to offer all citizens and businesses the same opportunities and rights.

As shown in Fig. 4-298 , national services have to be offered more to citizens, business and public agencies of other member states. Cooperation with the EU administration is also to become more important in the future.

Citizens and businesses using such cross-border eGovernment applications do not differentiate between the different areas of responsibility of national administrations, instead they expect a uniform, multilingual and consistent eGovernment offering between the member states. This means that in future it must be possible, for instance, for a building contractor in Italy wishing to relocate to Spain to be able to carry out the required communications with public agencies electronically from Italy. The contractor only communicates with one contact partner in this context. The necessary interaction between the different administrations in the member states takes place in the background as a cross-

98 Pursuant to the "European Interoperability Framework for Pan-European eGovernment Services" (EIF) v1.0, IDABC, 2004; http://ec.europa.eu/idabc/servlets/Doc?id=19528, page 12, Fig. 3

Figure 4-2: National and cross-border eGovernment interaction

Agency

Citizens

Business€

Citizens

Business€

Business€€

National eGovernment interaction Cross-border eGovernment interaction

MEMBER STATE A MEMBER STATE B

EU ADMINISTRATION Agency

Agency

G2C

G2G

G2B

G2C

G2B

G2GG2GAgency

Citizens

Business€

Citizens

Business€

Business€€

§§

§§ §§ §

44 SAGA 4.0

border eGovernment application without the contractor being aware of this or having to contact the individual agencies.

In addition to the registration of companies, the following areas were identified for cross-border applications: tax returns, applications for unemployment benefits, motor vehicle registrations. The EU services directive99 provides the corresponding framework for the implementation of these applications.

4.4.2 Optimization of administrative processesThe successful introduction and implementation of eGovernment calls for the examination of grown processes. Existing rules, processes and structures must be adapted and simplified in a suitable manner taking technical and legal circumstances into consideration. The mere electronic implementation of conventional procedures seldom leads to optimization.

Existing administrative processes are partly the result of historical developments and have become complex over the course of time as a result of many changes. The following measures are hence recommended before special applications are implemented electronically.

a. Simplification of processes and procedures

b. Deregulation

c. Shortening of process chains

d. Reduction in the number of interfaces

e. Avoiding iteration

f. Reduction in cycle and dead times100

First steps towards reducing red tape were designed to simplify processes and legal regulations for administration services. This is why Deutschland-Online101 covers services that concern several administration levels. The Federal Government's "Zukunftsorientierte Verwaltung durch Innovationen"102 [Future-orientated administration through innovation] programme triggers level-spanning processes which lead to an open dialogue on a joint vision for a future-enabled, network-orientated administration in Germany.

4.4.3 Qualification of staff The use and updating of standards, along with the development, operation and correct handling of IT-supported systems, calls for the continuous exchange of information and training. Many employees in the public sector are highly motivated when it comes to supporting eGovernment. This important asset must be exploited and increased in the interest of implementing eGovernment. This means that intensive training must be carried out for employees. Moreover, the administration must be made more attractive for IT experts.

99 Refer to section 4.5.4 "EU services directive – Creating a single EU market" on page 48 100 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter III, module

"Phase 3 – Analysis" 101 Refer to http://www.deutschland-online.de/102 Refer to http://www.verwaltung-innovativ.de/

SAGA 4.0 45

4.4.4 Involvement of usersThe use of eGovernment is strongly dependent on customer acceptance of the services offered. Full utilization of the savings potential of eGovernment is contingent upon the online services provided being accepted and used by potential users. Expectations among citizens, companies and public agencies as the specific target groups need to be identified on an ongoing basis. The service portfolio and the service rendering process must be adapted to these expectations.

4.5 Legal frame of referenceIn addition to the strategic goals and organizational frame of reference, legal guidelines must also be considered. The most important of these will be described in the following along with the legal adjustments in conjunction with the electronic signature, laws, ordinances and assistance for data protection and barrier freedom as well as the EU services directive. A detailed description of the legal adjustments implemented can be found in the Federal Government's E-Government-Handbuch103 [eGovernment manual].

4.5.1 Electronic signaturesElectronic signatures allow users of eGovernment applications to have themselves authenticated104. Sensible, practical and timely legal adjustments will make it possible for eGovernment to shape administrative processes efficiently and without media inconsistencies.

Legal adjustments

The legally binding nature of electronic communications is a crucial success factor for the implementation of eGovernment. What is hence needed is a digital solution for a signature with legally binding effect, i.e. the qualified electronic signature. Contrary to a simple or advanced electronic signature, a qualified electronic signature offers the highest degree of electronic replication of a handwritten signature. The legal adjustments required to enable the use of electronic signatures and to place these on the same standing as a hand-written signature have been completed in Germany. Besides amendments to the Signaturgesetz [Act on Digital Signature] to comply with European requirements, the electronic signature has also been integrated into the relevant blanket clauses in administrative and private law105.

Dissemination of the electronic signature

The dissemination and acceptance of qualified electronic signatures has been slow up to now due to the still prevailing disproportion between benefits and costs. For instance,

103 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter II, module: "Legal frame of reference for eGovernment"

104 Refer to section 8.5.4 "Technologies for authentication" on page 104, section 8.10 "Electronicsignature" on page 133 and section 8.10 "Electronic signature" on page 133

105 For information concerning the legal basis for the electronic signature, please refer to http://www.bsi.bund.de/ esig/

46 SAGA 4.0

qualified electronic signatures are only used up to now in a few mass processes and administration areas, for example, in invoicing.

The reasons for this are mostly related to security in the application of signatures and signature cards, the lack of interoperability between different signature applications, as well as the limited legal recognition in just a few individual states.

In order to bridge these security-related concerns, the Bundesnetzagentur (BNetzA) [Federal Network Agency] has already examined and certified products for qualified electronic signatures106. These products comply with the necessarily high security requirements of the Signaturgesetz107 (SigG) [Act on Digital Signature] and the Signaturverordnung108 (SigV) [Digital Signature Ordinance].

Furthermore, the costs involved in reorganizing internal administrative workflows, installing systems (smartcards, software, card readers) and ongoing use (the need to have the signature key regularly renewed) is a factor for administrations which, compared to the benefits, is still relatively high and hence hinders faster dissemination.

When it comes to citizens, on the other hand, there is a need to inform about the use and added value of electronic signatures. First practical applications show that smartcards are particularly attractive for citizens if they can use them for both private-sector and public services.

Federal Government initiatives and projects in the field of electronic signatures

The signature initiatives and projects of the federal administration are to be more closely coordinated with each other in the future in order to promote dissemination and acceptance, especially in conjunction with signature cards. The following cases are example of projects by the federal administration dealing with the use of signatures and signature cards:

a. The electronic health card109

The electronic health card covers the electronic prescription, the European health-insurance card, data for emergencies, documentation of medication as well as the electronic patient file. Furthermore, an electronic medical profession ID card is being developed which a doctor can use to generate a qualified electronic signature to replace the current, independent signature, for instance, to "sign" an electronic prescription for a patient. Field tests with the electronic health card began in December 2006.

b. The electronic ID card (ePA)110

The electronic signature function is also to be optionally integrated into the electronic ID card. "Optionally" means that the electronic ID card is prepared to hold a qualified signature certificate, but the certificate itself must then be loaded into the memory chip

106 Federal Network Agency (BNetzA): http://www.bundesnetzagentur.de/enid/Elektronische_Signatur/Produkte_pi.html

107 Act on the boundary conditions for digital signatures (SigG): http://www.gesetze-im-internet.de/ sigg_2001/

108 Digital Signature Ordinance (SigV): http://bundesrecht.juris.de/sigv_2001/109 Refer to http://www.die-gesundheitskarte.de/110 Refer to http://www.epass.de/

SAGA 4.0 47

by the holder of the ID card. This freedom of choice means that the card can be used according to specific needs. The integration of biometric information and an authentication function round off the future electronic ID card, making it reliable proof of identity and a universal, future-enable and secure key for eGovernment and eBusiness.

c. The electronic tax return (ELSTER)111

Within the scope of the electronic tax return, citizens and businesses can, for instance, complete and submit online VAT returns, wage tax returns or wage tax certificates. It is also possible to view tax accounts; this requires a signature card which is supported by the system. An overview of such signature cards is provided on the website112.

4.5.2 Data protectioneGovernment offers a host of options and rationalization potential in the IT sector. Ideally, data from the most varied contexts is gathered once only by a central function and could be subsequently available for any de-centralised purpose and use.

However, when electronic data is interchanged within and between public agencies, data protection requirements must be considered and implemented by way of suitable technical and organizational measures. Personal data, in particular, may not be gathered, processed or disclosed for any purpose other than the use explicitly contemplated by law.

The Federal Government's E-Government-Handbuch [eGovernment manual] includes a separate module113 with comprehensive information concerning the issue of data-protection-compliant eGovernment. Under the title "Technological Data Protection", the Federal Commissioner for Data Protection and Freedom of Information provides orientation aids for certain application cases114, such as the use of document management systems or cryptographic methods.

4.5.3 Barrier-freedomMore than eight million disabled people, 6.6 million of whom are severely disabled, live in Germany. People with impaired vision and physical handicaps are especially dependent on technical aids as a precondition for using the Internet, such as large screens or a magnifying-glass function, Braille line, voice output, etc. In order to optimally enable these devices for eGovernment applications, a host of rules and requirements must be considered during programming, designing and editing.

On 1 May 2002, the new Behindertengleichstellungsgesetz115 (BGG) [Law on Equal Opportunities for the Disabled] came into effect. The aim of this Law is to overcome

111 Refer to http://www.elsteronline.de/112 Refer to https://www.elsteronline.de/eportal/Sicherheit.tax#sigkarte113 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter II, module:

"Data-protection-compliant eGovernment" 114 Refer to http://www.bfdi.bund.de/, "Startseite Datenschutz" ["Home" page - Date

protection] > "Themen" [Topics] > "Technologischer Datenschutz" [Technological Data Protection]

115 Law on Equal Opportunities for the Disabled (BGG): http://www.gesetze-im-internet.de/bundesrecht/ bgg/

48 SAGA 4.0

disadvantages for disabled people, to ensure their discrimination-free participation in social life and to enable them to live an autonomous independent life.

This is also applicable to the use of the Internet. The most important criteria and references are to be found in the Ordinance on the Creation of Barrier-free Information Technology pursuant to section 11 of the BGG (Barrierefreie Informationstechnik-Verordnung – BITV116) which came into force on 24 July 2002. This ordinance specifies the Web Content Accessibility Guidelines117 1.0 (WCAG 1) from 1999 as the technical standard. The BITV is binding upon public agencies of the federal administration118 since 1 January 2006 and applies to:

a. website and Internet offerings,

b. intranet sites and offerings which are available to the general public,

c. IT-based graphic user interfaces which are available to the general public.

4.5.4 EU services directive – Creating a single EU marketThe EU services directive119 was adopted on 12 December 2006 by the European Parliament and the European Council. The aim of the directive is to reduce red tape in the European Union (EU), to promote the cross-border provision of services120 and hence the resultant implementation of a uniform, single EU market. This directive must be implemented by the end of 2009. Within the scope of electronic procedures, it covers, for instance, the demands for:

a. Points of single contact"Member states shall ensure that it is possible for providers to complete the following procedures and formalities through points of single contact:a) all procedures and formalities needed for access to his service activities, in particular, all declarations, notifications or applications necessary for authorization from the competent authorities, including applications for inclusion in a register, roll or a database, or for registration with a professional body or association;b) any applications for authorization needed to exercise his service activities." (Article 6 (1))

b. Ensuring access to and exercising of services"Member states shall ensure that all procedures and formalities relating to access to a service activity and to the exercise thereof may be easily completed, at a distance and by

116 Ordinance on the creation of barrier-Free information technology pursuant to the Law on Equal Opportunities for the Disabled (BITV): http://www.gesetze-im-internet.de/bitv/

117 Refer to http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/ 118 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter II, module:

"Barrier-free eGovernment" 119 Directive 2006/123/EC of the European Parliament and of the Council of 12 December 2006

on services in the internal market: http://ec.europa.eu/internal_market/services/services-dir/index_de.htm

120 Contrary to the customary use of the term "service" in conjunction with eGovernment (refer to section 4.1.2 "The term "service" in eGovernment" on page 35), the following definition of a service is used in conjunction with the EU services directive: "[...] any self-employed economic activity, normally provided for remuneration" (article 4, para. 1)

SAGA 4.0 49

electronic means, through the relevant point of single contact and with the relevant competent authorities." (Article 8(1))

c. Taking common standards into account"The Commission shall, in accordance with the procedure referred to in Article 40(2), adopt detailed rules for the implementation of paragraph 1 of this Article with a view to facilitating the interoperability of information systems and use of procedures by electronic means between Member States, taking into account common standards developed at Community level." (Article 8 (3))

4.6 Processes in eGovernment

4.6.1 Levels of interactioneGovernment services can be generally broken down according to interaction levels, i.e. information, communication and transaction121.

Information covers the provision of information to people, businesses and other members of society. Users on this level merely act as recipients of information. This area is the most developed level, and almost all public institutions are present on the Internet with an website.

Many of these information systems are supplemented by communication solutions with interactive and participation services which enable the exchange of news, messages and information. These services range from simpler solutions, such as e-mail or web-based discussion forums, right through to more complex applications, such as video conference systems for telecooperation. In this respect too, the development status of German administrations can be described as being well advanced.

Transaction applications feature the highest level of interaction. This area covers the actual provision of services in the public administration. These applications include, for instance, the electronic receipt and processing of applications or orders as well as the provision of forms which are filled in on the computer and directly sent to the proper recipient. Electronic payment or tendering systems also belong to this category.

Compared to other levels of interaction, transaction services have been implemented to a lesser extent up to now. Public Key Infrastructures (PKIs) are an important precondition when it comes to ensuring the authenticity and confidentiality of the data exchanged between the different parties. The electronic exchange of documents with legally binding effect still involves technical and organizational challenges for public administrations and a satisfactory solution has yet to be found here. Another adverse factor is the currently sparse dissemination of the electronic signature in all parts of society.

4.6.2 Relationships in interactionBesides the classification in terms of interaction levels, the various partners involved in eGovernment can also be differentiated122, refer to Fig. 4-1 on page 42:

121 Refer to [v. Lucke et al. 2000], page 3122 Refer to [v. Lucke et al. 2000], page 3

50 SAGA 4.0

a. Government to citizen (G2C)Electronic interaction between citizens and the administration – this area also includes non-profit organizations

b. Government to business (G2B)Electronic business relations between the administration and the business sector

c. Government to government (G2G)Electronic relations between different public agencies and public administration institutions

Administration customers are hence citizens, business and other administrations. The focus in this case is on the G2C and G2B interaction relations. Relations between public agencies (G2G) are handled within the framework of the relevant transaction services between administrations and citizens and/or businesses. Communications within a public agency (government-to-employee, G2E) are not explicitly addressed in this context.

4.6.3 Transactions in eGovernmentAs mentioned earlier in section 4.6.1, public administration services not only cover pure services, but also rights and obligations. A functional classification of administrations is necessary as a precondition for standardizing the different types of administrative activity – and hence the possible transactions. Generally valid types of transactional services can be identified on this basis.

Transactional service types

The German administration can be divided into service and intervention functions based on responsibilities and legal forms. Different service types can be identified and classified as service-type and intervention-type services on the basis of the different categories of functional administrative branches.

Services mean that citizens or a business enterprise demand from the administration a service or benefit, i.e. the citizen or business initiates the process. Services include:

a. Applications for government money

b. Granting of subsidies

c. Subsidy and promotion measures

d. Approval procedures

Intervention is a case where the administration enters into the citizen's legal sphere, encroaching upon the citizen's freedom or property and/or imposing obligations upon the citizen. In this case, certain measures are initiated by the administration. Cases of intervention are:

a. Administrative fines

b. Criminal prosecution procedures

c. Legal proceedings

SAGA 4.0 51

d. Collection of taxes

e. Collection of customs duties

f. Registration obligations

Public procurement represents another service type where the government acts as the customer for businesses. Contracts for goods and services are subject to defined administrative procedures.

Process-related structure of transaction services

The individual transaction types can be broken down further into individual sub-steps. The sub-steps consist of one or more actions in which different actors are involved. Examples of sub-steps, actions and roles related to the service area will be discussed in the following. This methodological approach can then be used as a basis for developing similar process models for any other transaction type.

The sub-steps, which are correlated with each other and explained in more detail in Fig. 4-3 and in Table 4-1, are now defined for the services area. Every sub-step involves different actions and roles which are attributed to different actors. The "application" sub-step, for example, includes the actions of submitting, transmitting and receiving the application.

Figure 4-3: Sub-steps of transaction services

Information

Application

Processing

Decision

Comment and opinion

Collection of administrative

fees

Archiving

Payment ordisbursement of

funds

Control of fundapplication

Other procedures(e.g. appeal)

1

2

3

5

4

6 7

10

8

9

52 SAGA 4.0

The applicant's role is typically performed by a citizen or company. At the public agency, the post office – ideally a virtual one – receives the application and passes it on to the officer in charge.

In analogy to this procedure, the other sub-steps include further actions and roles which are summarized in the table below.

Sub-steps Actions Roles

1 Information Provision of information Editorial team

Information request Interested party

2 Application Submission of application Applicant

Transmission of application (Virtual) post office

Receipt of application Officer

3 Processing Examination of the case Officer, superior, other officers

Request for information Officer, superior, (virtual) post office, other officers

Provision of information Applicant, (virtual) post office

4 Comment and opinion

Information evaluation Officer, superior, other officers

5 Decision Writing the decision Officer, superior

Service of the decision Applicant, (virtual) post office

6 Collection of administrative fees

Collection of fees Payor, (virtual) cashier's office

7 Payment or disbursement of funds

Payment Payee, (virtual) cashier's office

8 Control of fund application

Examination of the case Officer, superior, other officers

Request for information Officer, superior, (virtual) post office, other officers

Provision of information Payee, (virtual) post office

9 Archiving Archiving Officer, records management unit

10 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 the section on "Transactional service types" on page 50 must necessarily include all the sub-steps. Depending on the particular process, sub-steps can be carried out repeatedly during the life of a case.

4.7 Modules for the implementation of eGovernment applications

The analysis of service types presented in section 4.6 "Processes in eGovernment" on page 49 and the related identification of sub-steps, actions and rules can be used as a basis for

SAGA 4.0 53

identifying functional modules which – given the required configuration possibilities – can be used to implement different procedures using information technology. The potential applications of these modules are dependent upon the quality of the process analysis and the chosen software architecture123.

The following types of modules can be defined in conjunction with the above-described procedure.

a. User interfaceThe analysis of the different roles leads to a need to develop certain modules which provide functions for accessing the eGovernment application. This includes a standardized, easily recognized user interface for user and role management functions as well as functions for authenticating users in the system.

b. Process modulesThe actions identified are standardized, if necessary, and implemented as a service or system and defined with priorities depending, for instance, on the potential frequency of use in the implementation of the business logic.

c. Infrastructure modulesOther modules standardize and implement communication with the other components of electronic procedures.

The German federal administration's one-for-all services (OFA services) were largely created within the scope of the BundOnline Initiative124 and are described in more detail on the KBSt website125 as examples of such modules. The creation of specialist applications on the basis of reusable services and systems is outlined in chapter 6 "Computational viewpoint:Reference software architecture" on page 65.

123 Refer to chapter 6 "Computational viewpoint: Reference software architecture" on page 65124 Refer to http://www.bundonline2005.de/125 Refer to http://www.kbst.bund.de/efa

SAGA 4.0 55

5 Information viewpoint: Standardization of data models

This chapter describes as the information viewpoint according to RM-ODP126 how interoperability between applications is established and/or improved by standardizing data models using suitable modelling methods.

5.1 Levels of interoperabilityOne important SAGA goal is to secure the interoperability of eGovernment applications, refer to section 1.3 "Aims"on page 12. Defining the technology viewpoint on XML as the standard for exchanging data127 merely provides a technical basis for this. Although XML does offer the required technical basis, but just like a series of correct words in a certain language do not necessarily make a sensible sentence, XML alone is not sufficient when it comes to warranting interoperability between applications. In order to be able to ensure that data can be sensibly interchanged between systems and further processed, it is vital that interoperability be secured, not just on a technical level, but also on an organizational and semantic level.

Organizational interoperability

Organizational interoperability primarily determines when and why certain data is exchanged. This means that within the scope of organizational interoperability, processes which result in the interchange of data are coordinated with a view to legal parameters (e.g. legislation and regulations).

Technical interoperability

Technical interoperability on the other hand refers to the mere possibility to exchange information. Technical interoperability includes the definition of transmission routes and protocols (e.g. SOAP, HTTP, FTP, IP, SMTP). The respective standards are referenced in the technology viewpoint, for instance in section 8.7 "Communication" on page 121. A common language for data description is the required technical precondition for interoperability. Section 8.6.6 on page 109 identifies XML as the mandatory standard for exchanging data.

Semantic interoperability

Semantic interoperability is given when two systems exchange data in such a manner that the data is interpreted in the same way by both communication partners and misunderstandings are ruled out. This applies not just to the form but also and especially to the content of the data transmitted.

126 Refer to chapter 3, "Architecture model for eGovernment applications”, section 3.4 "Computational viewpoint” on page 34

127 Refer to section 8.6.6 "Interchange formats for data ” on page 109

56 SAGA 4.0

Semantic interoperability is achieved by defining a uniform presentation form and semantics for the elements of the XML files exchanged. This definition can be achieved, for instance, by specifying concrete data models in the form of XML schemas (XSD) or by a Regular Language Description for XML New Generation (Relax NG)128.

Moreover, the documentation of the schemas must ensure that the constituent parts are interpreted in a uniform manner. For instance, it must be documented whether an element, e.g. "Street", also includes the house number within an address, or whether an element, e.g. "First name", can contain several first names or the forename used only.

Sensible processing of the data content hence often requires prior definitions via the schemas. For instance, in order to make it possible to compare details of occupations, it is necessary to define certain spelling and wording, because software simply comparing the profession of an "interpreter" and "translator" will not find any match. If, however, the use of the standard classification of occupations by the German Federal Pension Insurance were specified, all data records for translators as an occupation would be given the value "8220". This would make it possible to compare data and semantic interoperability would be established. The use of such uniform code lists is hence a suitable way to establish semantic interoperability. In addition to this, the use of code lists also improves the quality of the data to be processed. The codes presented in the selection lists prevent, for instance, wrong spellings and non-plausible data from being entered in the free-text fields.

5.2 Purpose of standardizing data modelsAs already shown in section 5.1, the definition of XML as the standard for data description in SAGA129 merely secures technical interoperability for the interchange of data between applications. Due to the flexibility of XML, however, this definition alone is not sufficient to ensure the standardization of data models. The components of data models especially, for instance, the address and name of an individual, which occur in many different eGovernment applications, are presented in a number of ways. There is no semantic interoperability since the data model in each application can be described in a different manner in XML. Standardizing these data models can help to avoid variants and improve the interoperability of applications based on the same standardized data models. First results with the standardization of data models have already been achieved.

Private sector standardization projects have shown that any attempt to achieve full-scale standardization of data models is usually doomed to fail. The standardization activities within the scope of Deutschland-Online hence focus on communication interfaces for electronic data interchange in two separate areas. The first area is the standardization of specific data models and the second area is the standardization of general data models, so-called core components.

Specific data models

Specific data models are understood to be those data models which have a strong reference and which can usually only be used in one area of application even if several public

128 Refer to section 8.3.2 "Interchange formats for data models” on page 96129 Refer to section 8.6.6 "Interchange formats for data ” on page 109

SAGA 4.0 57

agencies may be involved in the exchange of specific data. One example of such a data model is "XMeld" from the field of citizen registration services.

General data models

Contrary to specific data models, general data models – also referred to as core components130 – are data models that are used in many different areas of application. Examples of such data models are "Name" and "Address".

5.3 The Deutschland-Online "Standardisierung" [Standardization] project

5.3.1 Task and project aimNo. 2 of the Deutschland-Online action plan131 finds that binding, uniform standards for data interchange are a vital precondition for consistent electronic business processes in the public administration in Germany.

In light of this, the Deutschland-Online "Standardisierung" [Standardization] project was set up as one of six prioritized Deutschland-Online projects and handed over to the Federal Government (represented by the Federal Ministry of the Interior132) and the federal Land of Bremen (represented by the OSCI steering group133) as the lead unit.

The purpose of the project is to support and coordinate the development and provision of technical standards for electronic data interchange (XÖV standards), so that electronic administration processes can be implemented efficiently and in a uniform manner.

The results of the "Standardization" project will be used predominantly in XÖV projects134. Common methods, tools and infrastructures are to be created for the XÖV projects. Examples of such XÖV projects are:

a. "XMeld" (citizen registration services)

b. "XBau" (building/construction)

c. "XJustiz" (electronic legal communications)

d. "XDomea" (workflow management)

e. "XKfz" (vehicle registration services)

f. "XFinanz" (finance)

130 Refer to section 5.4.4 "Core components” on page 63131 For more detailed information, please refer to section 4.3.2 "Deutschland-Online - The joint

eGovernment strategy of the Federal Government, federal-state governments andmunicipalities.” on page 38 and also refer to http://www.deutschland-onl ine.de

132 Refer to the Co-ordinating and Advisory Agency of the Federal Government for Information Technology in the Federal Administration, http://www.kbst.bund.de/

133 Refer to the OSCI steering group, http://www.osci.de/134 Refer to http://www.osci.de/, navigation items "XÖV-Koordination" [XÖV coordination] >

"XÖV-Projekte" [XÖV projects]

58 SAGA 4.0

5.3.2 XÖV working groupsThe Deutschland-Online "Standardisierung" [Standardization] project is broken down into four sub-projects: "Bestandserhebung und Gesamtkonzept" [Stock-taking and overall concept], "Technische Infrastruktur für XÖV" [Technical infrastructure for XÖV], "XÖV-Koordination" [XÖV coordination] and "Kommunikation, Öffentlichkeitsarbeit und Vertretung in Gremien" [Communication, PR work and representation in committees]. A more detailed presentation of the overall project can be found in the project manual135.

The "XÖV-Koordination" [XÖV coordination] sub-project has two working groups for the development of uniform methods and concepts for standardizing specific XÖV standards and the general XÖV core components:

a. The "Datenkonferenz" [Data conference] working group: In this working group, experts – above all, federal-agency representatives of the individual XÖV projects (e.g. XMeld, XKfz) – are working on the identification and definition of general data models (XÖV core components). This hence ensures that the requirements of the XÖV project, which already exist, are included in the data standards and the standards created can be reused in the different XÖV projects. Furthermore, within the scope of the working group, a procedure was developed for the application and coordination of XÖV core components. Work on the individual topics was carried out in various sub-working groups.

b. The "Auslieferung und Implementierung von XÖV-Standards" [Delivery and implementation of XÖV standards] working group: This working group addresses the practical use of the completed XÖV standards. The working group is responsible for defining the following:i. general rules for describing test cases in XÖV projects in order to check the

compliance of specific IT applications which implement this XÖV standard,ii. the name and design rules for XML schemas,iii. concepts for using and updating code lists, as well as iv. the procedure in the event of a change of XÖV standards.

5.3.3 XÖV frameworkThe XÖV framework136 describes a procedure model based on the V-Modell XT137 for implementing XÖV standardization projects. The various project phases which an XÖV project should pass through are described along with the rules for the successful completion of these phases, refer to Fig. 5-1.

135 Refer to http://www.deutschland-online.de/, navigation item "Vorhaben" [Projects] > "Priorisierte Vorhaben" [Prioritized projects] > "Standardisierung" [Standardization] > "Downloads & Informationen" [Downloads & Information] > link "Projekthandbuch" [Project manual]

136 Refer to XÖV-Framework v1.0 - Leitlinien für die XÖV-Standardisierung [XÖV Framework v1.0 – Guidelines for XÖV Standardization], October 2006, Fig. 1, http:// www.deutschland- online.de/, navigation items: "Vorhaben" [Projects] > "Priorisierte Vorhaben" [Prioritized projects] > "Standardisierung" [Standardization] > "Downloads & Informationen" [Downloads & Information] > link "XÖV-Framework" [XÖV Framework]

137 Refer to the XT V model, http://www.kbst.bund.de/v-modell and section 1.6 "Relationshipswith other eGovernment documents” on page 13

SAGA 4.0 59

The aim is provide uniform quality and evaluation criteria for the status of current and future XÖV standardization projects. Uniform evaluation criteria, on the other hand, are an important precondition for the binding recommendation of XÖV standards and hence for the use of the project results and the success of the standardization projects.

The main goals of the XÖV Framework are:

a. to improve interoperability,

b. to reduce costs through reusability, and

c. to reduce project risks by exchanging experience and learning from best practices.

The XÖV Framework distinguishes between two types of XÖV projects:

a. XÖV base projects (B projects): The aim of B projects is to create a standardized data model or an XML schema.

b. XÖV expanded projects (E projects): E projects go beyond the aim of B projects and attempt to improve and standardize inter-agency processes (XÖV standards, for instance, for XMeld).

5.4 Support for data model developersDue to the growing networking of applications, securing semantic interoperability through suitable data modelling is becoming more and more important. Data modelling in complex eGovernment projects poses ever-greater challenges for those in charge of such projects. In a first step towards standardized data models, the Federal Ministry of the Interior is supporting developers of data models through measures which are described below, refer also to Fig. 5-2.

Figure 5-1: Goals, rules and project types in the XÖV framework

Rules for XÖV projectsXÖV goals XÖV project types

The project order includeds a benefit assessment.

The possibility to use existing, specific modules was examined.

…

Improved interoperability

Lower project risks

Lower costs of XÖV standardization

Process-orientatedXÖV-expanded

projects(E projects)

Data-orientatedXÖV basic projects

(B projects)

supports is a mandatory rule for is an optional rule for

Processes were standardized also across administrations.

XGenerator was used to createschemas / documentation.

60 SAGA 4.0

5.4.1 Guideline for developers of process and data modelsOn its website, the KBSt offers a guideline for developers of process and data models138. This guideline provides those in charge of projects with practical assistance and recommendations for action during their day-to-day work, and describes how high-quality data models can be developed.

The guideline is designed to address the entire process modelling and data modelling complex. It also features information on how to prepare modelling, on modelling itself, and on analyzing and optimizing existing models. All these topics are addressed in the guideline and illustrated by examples.

5.4.2 XML Infopoint and XRepositoryThe KBSt unit also provides another tool on its homepage, i.e. the XML Infopoint139. This is where information is gathered on planned, current and completed projects with an XML reference. Synergies can be achieved and work reduced by making use of information publicly available as well as specifications of projects with a similar topic, or by contacting those in charge of other projects.

In Spring 2008, XML Infopoint is to be replaced by XRepository.

138 Refer to "Leitfaden für Entwickler von Prozess- und Datenmodellen" [Guideline for developers of process models and data models], KBSt, 2007, http://www.kbst.bund.de/mo dellierungsleitfaden

139 Refer to XML Infopoint, http://www.kbst.bund.de/xml-technologie

Figure 5-2: Support for data model developers

Guidedocument

Modeller

XRepository

XGenerator 2.0

Recommendations for actionand assistance Feedback

Corecomponents

Import of owndata models

Identification of relevantdata models

Project-specificrequirements

Basics for semanticinteroperability

Generation ofXML schemas and

documentation

Project-specificrequirements

SAGA 4.0 61

The main aim of XRepository is to publish specific and general data models140, so that they can be reused in projects, thus leading to savings and improved interoperability. A focus is also placed on standardized data models (XÖV standards and core components).

In order to obtain a large content base, the obstacles to the inclusion of data models are kept as low as possible. This can, however, be opposed by the demand for higher quality. XRepository will hence be set up on several levels, refer to Fig. 5-3.

The first level is a collection which includes the required broad base of data models. Registered users can include models here without significant obstacles. Only a brief pre-examination is designed to prevent the inclusion of irrelevant or unsuitable content. Users of XRepository are informed that when these models are used, high quality and compatibility with future standards are not warranted. Despite this, by reusing the models from the XRepository collection, savings can be made since double work is avoided. Using models from the collection is particularly good when no interoperability with other systems is required.

In order to achieve high quality despite the low requirements for the XRepository collection, a second level will be introduced: a catalogue of quality-assured data models. This catalogue only includes those models from the collection which fulfil defined quality requirements141.

In the third level of XRepository, the standards, i.e. the XÖV core components (general) and the XÖV standards (specific), will be included. The standardized data models fulfil the

140 Refer to section 5.2 "Purpose of standardizing data models” on page 56141 The quality requirements will be described in detail on the homepage following

publication of XRepository.

Figure 5-3: Standardization process in XRepository

COLLECTION

CONTINUANCE LISTData models to be

retained

REJECTION LISTof rejected data models

Proposal list for specificdata models

Proposal list for generaldata models

Positively rated specificdata models

Positively rated generaldata models

RecommendedXÖV standards

RecommendedXÖV core components

Quality assurance

Standardization

Mapping, ifnecessary

CATALOGUE

STANDARDS

Specific datamodels

General datamodels

Rejection

Rejection

62 SAGA 4.0

quality requirements of the catalogue. Care will be taken to ensure that no data models exist in the catalogue which compete with the standards. A continuance list will be set up for those models of the catalogue which will be replaced by standards. Data models in this continuance list can still be used. New projects, however, should use the standards. In order to make it easier to replace established models of the catalogue with standards, migration instructions can be provided in XRepository which facilitate the transfer of established models to XÖV core components or XÖV standards, respectively. Mappings could enable the use of standards for data interchange without having to internally replace established data models.

The use of the standards for data modelling shown in XRepository is recommended particularly for those eGovernment applications which involve data interchange across agencies and across applications.

The standardization of data models – and especially the development of core components - is being promoted not just in Germany, but also on an international level, and repositories are being created for their dissemination. On international level, UN/CEFACT is the leader in the development of core components142. As soon as German standards come into contact with international data traffic, an exchange with international standardization projects will be sought at an early point in time.

5.4.3 XGenerator 2.0XGenerator 2.0143 is a tool provided by the Federal Ministry of the Interior that can be used to automatically generate specifications for XML-based data interchanged from UML models. These specifications can be made available in machine-readable form to the software implementations.

A specification in this case consists of a number of machine-readable XML schemas and documentation for the application developer which is consistent with this. The use of XGenerator 2.0 avoids the difficult, manual updating of the schemas and the documentation which would otherwise be necessary. In the event of modifications of the specific model, XGenerator 2.0 can be used to automatically generate the new XML schemas and the documentation.

XGenerator 2.0 offers the following functions, refer to Fig. 5-4:

a. Validation of the UML models against the XÖV-UML profile144

b. Automatic generation and validation of XML schema files from UML models

c. automatic generation of DocBook files145 from UML models

142 Refer to Core Component Library, http://www.unece.org/cefact/codesfortrade/codes_index.htm#ccl

143 Refer to XGenerator 2.0, http://www.kbst.bund.de/xgenerator144 A UML profile is a standard mechanism in order to individually expand the UML

specification. The XÖV-UML profile defines, among other things, a number of specific additional annotations (stereotypes) in order to generate XML schemas and to steer their documentation, refer to http://www.osci.de/, navigation items: "XÖV-Koordination" [XÖV co-ordination] > "XÖV-UML-Profil" [XÖV-UML profile].

145 DocBook is an open document format that was standardized by OASIS (Organization for the Advancement of Structured Information Standards) and is ideally suited for generating print and online formats, e.g. PDF and HTML.

SAGA 4.0 63

5.4.4 Core componentsThe media-consistent electronic exchange of data, also across various fields, calls for general, standardized data models, for example, when personal data is to be exchanged between citizen registration and vehicle registration services. The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) developed the Core Components concept precisely for this purpose. Within the scope of the Deutschland-Online "Standardization" project, a series of core components were created and presented to the Co-operation Committee for Automatic Data Processing for the Federal-government, Federal-state Government and Municipal Administration Sector (KoopA ADV) for its approval and were subsequently made available to Germany's administration. These core components include, among others:

a. Natural person

b. Name of a natural person

c. Organization

d. Authority

e. Address

f. Gender

g. Religion

h. Marital status

i. ID document

Figure 5-4: How XGenerator 2.0 works

Specialist groupdefines the

specific model

Documentation

XML schema

UML model

Refined specific modelwith an XÖV UML profile

Specification developeradds information for the

generation of schemas and their documentation

XGeneratorgenerates

XGeneratorgenerates

64 SAGA 4.0

j. Language

k. Country

l. Time period

Developers of data models can use these core components as templates and, by omitting attributes, can restrict value ranges and/or quantities in order to create a specific component which meets the requirements of the respective data interchange. Redundant-free modelling (information cannot be stored in different elements) and clear documentation of the core components help to ensure that data can be exchanged without human intervention. The core component "address", for instance, ensures that the house number is an attribute of its own and may not be saved together with the name of the street. The only way to avoid conflicts in automated data interchange is to ensure that all communication partners model their data according to the same rules.

The involvement of the XÖV projects in the development of core components ensures that they fulfil these requirements. The DOL "Standardisierung" [Standardization] project ensures that new requirements are considered when core components are updated and that additional core components are created according to demand.

Final versions and drafts of core components and specific components are to be stored in future in the so-called XRepository and are to be made generally available.

SAGA 4.0 65

6 Computational viewpoint: Reference software architecture

The computational viewpoint according to RM-ODP146 describes the architectural structure of distributed eGovernment applications in abstract form and omits implementation details. In this chapter, issues of architecture are explained and the resultant reference software architecture is presented. This chapter also offers assistance for designing and developing long-term eGovernment applications for the federal administration which are suitable for operation, maintenance and further development.

The term "Reference Software Architecture" refers to an ideal architecture type of the federal administration. It describes the design layout of eGovernment applications (specifically: services147 and systems148) of an administration or – more generally – of an organization.

Section 6.1 describes the general, non-functional requirements for developing applications which must be viewed independent of use in eGovernment. The extent of these requirements influences the architecture decisions to be made.

Section 6.2 "Implementation options and architecture paradigms" presents the main alternatives and guidelines for architecture decisions. The options and paradigms reflect the current state of the art in software architecture.

Finally, a reference software architecture for eGovernment applications is developed in section 6.3 based on the requirements and alternative solutions contained in sections 6.1 and 6.2.

6.1 General requirements for software applications

The computational viewpoint in SAGA provides assistance when developing eGovernment applications with a view to the aims identified in SAGA149 and to the guidelines and requirements presented within the scope of the examination of the enterprise viewpoint in chapter 4.

In addition to the specific functional requirements for developing an eGovernment application, which can be derived, for instance, from the technical specification, there is a series of general requirements which are relevant for the architecture. The following list of such non-functional requirements is arranged alphabetically and does not reflect any

146 Refer to chapter 3 "Architecture model for eGovernment applications”, section 3.4 "Computational viewpoint” on page 34

147 Services are entities which provide functionalities for applications. The use of services also makes it possible for external applications to manage the resources provided by the service. Services are specified via their interfaces and the functionality made available.

148 Systems are entities which provide the user with complex functionalities. If necessary, they use the services made available.

149 Refer to section 1.3 "Aims” on page 12

66 SAGA 4.0

weighting of the individual requirements with a view to software and technical aspects150. However, the aims of interoperability and reusability laid down in SAGA have an outstanding role to play.

a. ExtendibilityExtendibility refers to the economically reasonable ability to add new functionalities to the system, or to extend the existing functionality without any adverse effects on such functionality. Especially if eGovernment applications are operated over a long period of time, it must be possible to extend them as laws change.

b. Flexibility"Flexibility" generally refers to the ability to modify an architecture in order to meet with new, non-functional requirements in a cost-efficient manner. A topology that can be changed permits quick modification of a distributed architecture and hence improves non-functional requirements, such as availability, reliability and scalability.

c. InteroperabilityInteroperability refers to the media-consistent implementation of transaction services between special inter-agency applications. One organizational precondition for this is that the administration processes must be harmonized so that the eGovernment applications implemented can interact with each other.

d. OpennessThe "openness" feature of an eGovernment system is one of the crucial factors for its successful use. In order to allow existing and new systems to be easily integrated into other systems, such systems must have clearly defined and documented interfaces or must be so encapsulated that they can be at least integrated via portals.

e. PerformanceThe "performance" feature of a system generally refers to the ability to execute functionality quickly enough to warrant the usability of the system. A measure for performance is the capacity of a system, i.e. the ability to process a defined number of jobs per time unit.

f. SecuritySecurity describes the assurance that information can only be modified or published in compliance with the proclaimed security policy.Confidentiality, authenticity and traceability, as well compliance with the Federal Data Protection Act and the relevant chapters on security in the eGovernment manual must be ensured in the use of online services, refer also to chapter 8.1 "IT security concept" on page 91.

g. ScalabilityScalability 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. AvailabilityAvailability is a measure that shows how reliably an application makes functionalities, services or resources available.

150 Refer to [KBSt 2007]

SAGA 4.0 67

i. Updating capabilityeGovernment applications suitable for updating feature economically efficient operation and updating. Efficient updating must be possible for external technicians who were not involved in the development of the application without requiring extensive familiarization or training.

j. ReusabilityReusability refers to the repeated use of an application or its components with the same or similar services. This avoids redundant development. Reuse is possible on several different levels of abstraction, e.g. exchange of experience between agencies and the use of joint data and process models, architecture patterns and central services.

The concrete weighting of the different requirements depends on factors which must be identified and evaluated when developing the concept for the individual eGovernment applications. In the case of applications with very high access rates, for example, availability is likely to be more important, whereas security issues are more likely to have priority in the case of approval and licensing procedures.

Additional information can be found in the federal administration's "IT-Architekturkonzept für die Bundesverwaltung" [IT architecture concept for the federal administration] [KBSt 2007].

6.2 Implementation options and architecture paradigms

The following sections discuss the implementation options and architecture paradigms which should be observed when implementing eGovernment applications or which should be used to select suitable options. The options and paradigms reflect the current state of the art. Additional information can be found in the federal administration's "IT-Architekturkonzept für die Bundesverwaltung" [IT architecture concept for the federal administration] [KBSt 2007].

6.2.1 Component-based developmentA component is understood to be a software entity which can be used without the need for modification in software applications which are beyond the control of the component developer. Users normally do not have access to the source code of a component, however, they can adapt the behaviour of the component in the manner foreseen by the developers of the component.

Components offer their functionalities via export interfaces and, if necessary, can use the functionalities offered by other components in order to implement the functionalities offered; the use of these functionalities is specified in the import interface, refer to Fig. 6-1. Since the description of the functionalities offered and consumed by a component is independent of the actual implementation, implementations may be exchanged without the user realizing this and this offers many possibilities for the further development of the implementation.

68 SAGA 4.0

Another major improvement compared to purely object-orientated concepts is offered by standardized runtime environments for components in the form of application servers or light-weight frameworks which enable the declarative use of special, independent services, such as authorization, localization, persistence or transaction management for components. Since these functionalities no longer have to be implemented in the components, software creation is both easier and faster. Furthermore, the exchange and simple reuse of components is possible as contemplated in the paradigm for separating concerns in other application contexts. In order for components to be able to use the functionality of a platform, special component platform contracts must be implemented, i.e. components are always implemented for precisely one type of component platform.

6.2.2 Service-orientated software architectureThe term "service" refers to a concept from the business process modelling context which stands for the repeated execution of business activities. The approach described below requires services to be stateless – contrary to component-based development. Fig. 6-2 "SOAreference model" on page 69 provides an example of service rendering and service use in a Service Oriented Architecture (SOA). The individual levels in the illustration are merely used to show the logic breakdown and do not represent any tiers in the sense of a tier model.

Figure 6-1: Component-based development

Component 1

Export interface

Body

Import interface

Component 2

Export interface

Body

Import interface

Component platform

SAGA 4.0 69

Services make their functionalities available via interfaces (dark circles with a bright border in the middle of Fig. 6-2). How the functionality is performed is irrelevant for the user. The functionality of newly implemented services is carried out by components. Using connectors, the functionality of existing systems is subjected to modular encapsulation and made available as a service.

Users (bright circles with a dark border in the upper section of the Fig. 6-2) use the services either directly or integrate these into their business processes. These processes (white border) result from the composition of individual activities (circles). The activities use other activities within a composition. Each activity requires either manual access (light circle) and or can be mapped by services (dark circle). This mapping can be carried out on a stand-alone service or a composition, i.e. a combination of services (symbolized by the border around two service interfaces). The composition of existing services offers a higher value service for the business processes and users.

The technical strength of a service oriented architecture is that it makes it possible to combine existing functionalities irrespective of the technologies used to implement these functionalities. A service oriented architecture, however, must meet with certain preconditions:

a. For interaction between services and their users (the arrows in Fig. 6-2 in the direction of service interfaces and their compositions), a communication basis must be defined which is rooted in generally accepted standards151. The service must master these standards, so that it can be used.

151 Refer to section 8.7.1.2 "Middleware communication with applications outside theadministration” on page 123

Figure 6-2: SOA reference model

Serv

ice

deliv

ery

Serv

ice

use

Business processescomposed of activities

User

Service interfaceatomar and composed

Componentsfor implementing services

Operating infrastructureand data management

Service 1component

Service 2component

OFA servicecomponent

LegacysystemDBMS

ERPsystem

70 SAGA 4.0

b. Potential users must be able to receive information about the services available. A repository can provide this information and hence enable uniform access to services.

From an economic point of view, the service oriented architecture reduces the costs of developing and operating applications if a larger number of services are made available and are used by many applications. This then reduces the time and work involved in developing new applications because only the functionality which is not yet covered by existing services now has to be implemented. The central operation of services, in particular, helps to reduce costs thanks to a more economic use of resources and lower manpower demand.

A directory of electronic services for the public administration is being implemented by the Deutsche Verwaltungsdiensteverzeichnis (DVDV) [German Directory of Administrative Services]. This is where the connection parameters of the services, which are required for use, are saved, refer to section 7.4.1 on page 88.

6.2.3 Multi-tier architectureThe following section explains why both component-based as well as service-based multi-tier architectures support compliance with the requirements set forth in section 6.1.

Separation of business and data storage logic

The separation of business and data storage logic minimizes the dependency of systems or services on database manufacturers. In response to growing requirements, e.g. concerning performance or availability, the database can be exchanged without having to change the business logic. In addition to this, the same software can be reused with other database products with few difficulties.

Separation of presentation and business logic

Separating the presentation and business logic offers a technical solution with optimum support for multiple presentation channels, such as different browser types or mobile devices, e.g. personal digital assistants (PDAs). Besides this aspect, the separation of presentation and business logic significantly enhances the structure of the architecture, thereby substantially improving updating capabilities, trouble-shooting, flexibility, reusability and reproducibility whilst at the same time lowering costs in the medium term. Furthermore, such a separation enables the potential distribution of the application to several servers – where one server is responsible for the presentation tier and a second server for the business logic – and it is from here that the services are triggered which in turn can run on other servers. This has a positive impact on operation with regard to security, upgrading capability and scalability. Special attention should be paid here to communication because a less-than-optimum distribution adversely affects performance.

Separating client and presentation logic

In order to avoid having to install a separate client software for each application, uniform access is recommended via the browser, refer to section 8.5.1 "Access to information withcomputers" on page 101. Since barrier freedom and security require that eGovernment

SAGA 4.0 71

applications remain usable even if all active contents have been deactivated at the client end, the data must be processed at the server end in a separate presentation tier. Different presentations can be generated for different clients on the basis of the respective requirements.

Multi-tier architecture

The separation of client, presentation logic, business logic and data storage logic leads to a multi-tier architecture:

a. The client tier is where users and software interact. The data processed by the presentation logic as well as the user interface is visualized. The client tier hence represents different access channels reflecting different users, devices, transmission paths, as well as different application purposes in order to interact with special applications. SAGA refers to the following terminal devices:i. Web access via web browsers or special browser plug-insii. Mobile phones and personal digital assistants (PDAs)iii. External applications (e.g. ERP systems)

b. The presentation tier implements the processing of application data for the client (e.g. as a website) and the interaction between the user and the special application. The presentation tier includes all the standards for communication with the relevant terminal devices of the client tier.

c. The middle tier, also referred to as the business tier, implements the business logic irrespective of its presentation and processes the data from the persistence tier. This is carried out on the basis of services and by components when services are unable to perform this. This is where the program sequence is controlled and this steers interaction between the services and components.

d. The persistence tier is responsible for the storage of data objects. It abstracts from the database. The backend is the collective term for functionalities of the operating system,

Figure 6-3: Structural view - multi-layer architecture

Client

Presentation

Middle tier

Persistence / Backend

Com

mun

icat

ion

Secu

rity

Integration components

72 SAGA 4.0

specific databases as well as existing, non-SAGA-conformant special applications, legacy or ERP systems.

6.3 Reference software architecture for eGovernment applications

Interoperability, reusability, economic efficiency, openness and scalability are the key requirements for eGovernment applications152. The reference software architecture described is based on implementation options and architecture paradigms from section 6.2 which, in turn, are used to fulfil the general requirements contained in section 6.1. This architecture is based on multi-tier architectures and permits both the use of services as well as the direct use of components. Implementation should be object-orientated153.

6.3.1 Architecture decisionsDue to the heterogeneous requirements of the different public agencies, it does not make sense to define a reference software architecture based on just one architecture paradigm to be used for all applications. Instead, the approach which is most suitable must be sought for from case to case.

The possibility of a service-orientated approach154 should always be examined because this permits a high degree of flexibility, interoperability, reusability and openness. If an organization introduces a service oriented architecture, this usually requires close 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 by a service oriented architecture (e.g. response times).

b. The business processes to be supported are so complex that single activities can no longer be implemented as stateless services.

c. The flexibility of the service oriented architecture is not required.

Detailed recommendations for selecting the suitable architecture paradigms can be found in sections 3.4 "Architekturentscheidungen" [Architecture decisions] and 4 "Fallbezogene Architekturentscheidungen" [Case-related architecture decisions] of "IT-

152 Refer to section 1.3 "Aims” on page 12153 Refer to [KBSt 2007], section 3.3.1154 Refer to section 6.2.2 "Service-orientated software architecture" on page 68

SAGA 4.0 73

Architekturkonzept für die Bundesverwaltung" [IT architecture concept for the federal administration] [KBSt 2007].

6.3.2 Introduction of a service oriented architectureThe following section addresses the organizational challenges and the aspect of costs for the introduction of a service oriented architecture.

The main organizational challenges

a. The introduction of a service oriented architecture is a complex process because the application landscape is marked by a number of existing systems and there is little room for new development or adaptation. This is why such an introduction can take considerable time. The introduction should be carried out gradually, beginning with a pilot project.

b. A host of reusable services are created when services are developed not for a specific application but for many applications in terms of an overall IT structure within the meaning of a development plan for the entire application landscape. This calls for an IT architecture management function which is responsible for the planning and design of the overall IT architecture, refer to "IT-Architekturkonzept für die Bundesverwaltung" [IT architecture concept for the federal administration] [KBSt 2007]. IT architecture management is an ongoing process which involves both strategic and operational elements.

c. In contrast to customary architectures or architectures with largely closed individual applications, service oriented architectures have other, frequently more complex requirements or challenges regarding security. In a service oriented architecture, it is no longer the IT security of the individual special applications which has to considered, instead that of all services involved in a special application, which may be operated in a distributed manner, must be considered. These requirements must already be coordinated in the development process with distributed responsibilities and then later in operation.

d. Parallel development of services in different projects, which are to be used together in one application, calls for project-spanning project management, i.e. multi-project management. This is the only way in which project-spanning requirements can be fulfilled.

e. The project-spanning nature of a service oriented architecture has implications for the organization and performance of testing, for instance, due to a version change in a service. All applications using the service are then affected by test activities.

f. The independent further development of services by various suppliers means that changes must be coordinated within the scope of a change management system for all applications. Rules must be defined for new versions of services (release policy), such as the scope and the related test work for all suppliers.

g. Distributed responsibility for the development and operation of services calls for a Service Level Management for a suitable and economically sensible level of IT services, although when it comes to specific services, SLAs (Service Level Agreements) must be

74 SAGA 4.0

concluded between service users and service providers. IT operations must be organized in a process-oriented and service-oriented manner. The recommendations of the ITIL155 provide a suitable basis for this.

h. Service orientation calls for the development of new billing models which reflect the distributed development and distributed operation of the applications or services, respectively.

The introduction of a service oriented architecture leads to investments, especially at the beginning, because the use of new principles and technology means that training will be required for staff and the previously mentioned organizational challenges must be overcome.

6.3.3 Three-tier architecture for servicesWhen implementing a service with a multi-tier architecture according to section 6.2.3, the presentation tier is omitted, refer to Fig. 6-4. The reason for this is that the services perform their functionality from within the business logic, i.e. the middle tier. The user of the service is another application (client) which may itself be responsible for presenting the results. Service delivery and service use are carried out as described in Fig. 6-2 "SOA referencemodel" on page 69.

155 Refer to section 7.1 "IT Service Management with the ITIL" on page 79

Figure 6-4: Model of a three-layer architecture of services

Pers

iste

nce

/B

acke

ndM

iddl

etie

r

Componentsplatform

DBMSDBMSLegacysystemLegacysystemLegacysystem ERP systemERP system

Service user

Service userC

lient

Communication protocol

Servicesplatform

Integration componentsIntegration components

Servicecomponents

Serviceinterface

SAGA 4.0 75

6.3.4 Four-tier architecture for eGovernment systemsFig. 6-5 provides an example layout with a concrete structure for a multi-tier architecture of an eGovernment system based on the general description in section 6.2.3. It can be seen that the presentation tier consists of a Presentation Application Server which generates, for instance, HTML and XML data with Java Server Pages. The Business Application Server on the middle tier forms the backbone of the application and performs the special functionalities on the basis of services and components. Via application interfaces (or also service interfaces as shown in Fig. 6-4), external applications and services can access the eGovernment system whilst bypassing the presentation tier.

Legacy and ERP systems are integrated via the respective integration components. The systems provide their functionalities via application interfaces or service interfaces. Connectors may be needed in order to achieve modular encapsulation of the legacy systems.

6.3.5 SecurityIn order to implement the requirements for security, the design recommendations contained in the E-Government-Handuch [eGovernment manual] must be considered. The

Figure 6-5: Example model of a four-layer architecture of eGovernment systems

DBMS

Java Server Pages

HTML / XMLHTML / XML

Presentation Application Server

Integration components

Pres

enta

tion

Pers

iste

nce

/B

acke

ndM

iddl

etie

r

Business Application Server

Applicationcomponent

Applicationinterface

Business Application Server

Applicationcomponent

Applicationinterface

Web browserMobile device

Clie

nt

ERP systemLegacysystemLegacysystem

JMS

RMIJ2EE

SOAP

Servlets

76 SAGA 4.0

"Sichere Integration von E-Government-Anwendungen - SIGA"156 [Secure Integration of eGovernment Applications] and "Sichere Architekturen für Client-Server-Architekturen für E-Government" [Secure architectures for client-server architectures for eGovernment] modules in the sub-chapter on "IT und IT-Sicherheit" [IT and IT security] are particularly relevant. Although designed for component-based implementation, the architecture principles contained here can usually be applied to service oriented architectures on a one-to-one basis.

6.3.6 Reuse and integration of OFA offersWhen designing a new eGovernment application, an analysis is conducted in order to determine which services and systems have to be newly developed and which existing services and systems can be used. Special consideration must be given to the OFA services, OFA systems, infrastructures and OFA concepts on the KBSt website157.

The term "service" refers to a concept from the business process modelling context which stands for the repeated execution of business activities. The OFA services make their functionality available via interfaces. The properties of the implementation are fully abstracted.

Examples of OFA services

a. Payment platform (ePayment)

b. Directory service

c. GeoDataCentre (GDZ)

An OFA system is a uniform whole, a software entity, that makes a complex functionality available. OFA systems include the following:

a. Form Management System (FMS)

b. Content Management System (CMS)

c. Travel Management System (TMS)

Although the services of infrastructures are not specific to concrete eGovernment applications, they nevertheless have a key role to play in electronic communications between public agencies. The following infrastructures are available, for example:

a. Informationsverbund der Bundesverwaltung (IVBV)[Federal Administration Information Network]

b. Deutsches Verwaltungsdiensteverzeichnis (DVDV)[German Directory of Administrative Services]

c. Public-Key-Infrastruktur der Verwaltung (V-PKI)[Administration Public Key Infrastructure]

An OFA concept describes a generally reusable approach for the implementation of specific issues in eGovernment applications. The following concepts are available, for example:

156 Refer to [SIGA]157 Refer to “OFA offers and networks”: http://www.kbst.bund.de/efa

SAGA 4.0 77

a. ArchiSafe

b. Online-Beratung (online consultation)

If the data security OFA system158 is used, a separate client application (the OSCI client enabler) must be installed at the end of the users of the online service. However, the browser remains the client of choice for eGovernment applications which is why this scenario is not part of the reference software architecture.

More complex eGovernment applications come with integration components so that existing IT applications, such as OFA offers, legacy systems and especially non-SAGA compliant applications, can be integrated. These integration components – as shown in Fig. 6-6 – are directly located in the middle tier. They offer communication possibilities with applications, such as ERP solutions, in as far as these applications are not available as a

158 Refer to the data security OFA system ("virtual post office") http://www.kbst.bund.de/efa-vps

Figure 6-6: Integration of OFA offers

Presentation

Middle tier

Persistence / Backend

OFA system

Applicationinterface

Integration components

Presentation

Middle tier

Persistence / Backend

Specific application

Infrastructure

ERP system

Legacysystem ERP systemERP system

Serviceinterface

Externalapplication

Externalapplication

Middle tier

Persistence /Backend

OFA service

Serviceinterface

Client

Web browserMobile device

78 SAGA 4.0

service and can be triggered via a service interface. In the latter case, no special integration components are required.

SAGA 4.0 79

7 Engineering viewpoint: IT service management and reference infrastructure

This chapter describes operating processes and the establishment of an effective and secure infrastructure as the Engineering Viewpoint according to RM-ODP159. Today's data protection, data security, efficiency and availability requirements for eGovernment are setting high standards for operators of applications and technical infrastructures. This is why a suitable technical infrastructure has to be set up for the applications from the physical resources and suitably connected for users through the network level to the external services which can only be successfully and securely operated within the scope of ongoing processes of IT service management.

7.1 IT Service Management with the ITILAs a best practice, the "IT Infrastructure Library" (ITIL) provides an established basis for designing, implementing and managing essential control processes in IT.

During the preparation of SAGA 4.0, an upgraded ITIL, version 3.0, was issued. In order to use a tried-and-tested approach as a basis and to be able to refer to German literature, ITIL version 2.0, which is supported by KBSt documents, is presented in the engineering viewpoint.

7.1.1 Introduction to ITILITIL is oriented towards customers, services and processes and comprises eight closely inter-linked publications on main topics which address support for business processes by IT processes. IT service management is broken down into the following processes:

a. tactical processes for planning and implementing service requests (service delivery), as well as

b. operative processes to support the quality and economic efficiency of the services in day-to-day operation (support service),

which are introduced in brief in a study by BSI and supplemented with synergies with IT security which is also implemented as a continuous process160.

Successful IT service management requires interaction between the individual processes whilst mutual control also takes place. ITIL describes in this context the tasks of the processes, however, the specific demarcation can be chosen according to the specific circumstances. Since the processes must be continuously operated, this requires concrete responsibilities. According to ITIL, this means that roles must first be defined for the respective process managers which must then be filled by individuals. An individual can

159 Refer to chapter 3 "Architecture model for eGovernment applications", section 3.5 "Engineering viewpoint" on page 34

160 Refer to [BSI 2005]

80 SAGA 4.0

assume several roles in this context as long as this does not result in a conflict of interest and representation is secured. This means that when ITIL is introduced, the coordination of processes and responsibilities must begin.

The ITIL processes communicate with each other via commonly used information collections. The control of the processes depends heavily on reporting which is integrated into all ITIL processes in order to assure quality. Object success control is also supported by ITIL through the use of so-called key performance indicators.

7.1.2 Tactical IT Service Management processes (Service Delivery)

For eGovernment applications as services, concrete service requests by customers must be planned and lastingly implemented. For this purpose, ITIL calls for the operation of the Service Delivery processes.

Service Level Management

When developing a new eGovernment application, the service provider and the customer negotiate customer requirements as a concrete service offer in a service agreement (Service Level Agreement, SLA). This is where functionalities, as well as non-functional requirements, such as performance (according to the number of users active at the same time) or availability (with maximum downtimes and recovery times), are co-ordinated. The aim is to draw up a clear definition of the expectations of both sides regarding a new

Figure 7-1:Overview of ITIL processes

SERVICE SUPPORT

Incident Management

Change Management

Release Management

SERVICE DELIVERY

Service Level Management

Availability Management

IT Service Continuity Management

Capacity Management

Finance Management

Problem Management

Configuration Management

SERVICE DESKSERVICE DESK

SAGA 4.0 81

service. In addition to the first-time creation of an SLA, subsequent customer requests and the monitoring of compliance with the SLA are also handled by the Service Level Management process. This process steers and monitors both the performance and the quality of a service.

Availability Management

Availability Management steers the functional provision of eGovernment applications during the required working hours. The aim is to achieve cost-efficient control of uninterrupted availability in line with business requirements. Dependencies on external service providers, e.g. due to maintenance agreements, must also be considered.

IT Service Continuity Management (ITSCM)

IT is an important production factor; its continued functioning must be planned in IT Service Continuity Management (ITSCM) even under the impact of disasters in the ITIL process. This is carried out within the scope of Business Continuity Management (BCM) which ensures that the business processes are restarted in order to secure the required minimum production capacities.

Capacity Management

The economic use of IT resources should be controlled on a long-term basis for competitive services using the ITIL Capacity Management process.

Financial Management

Controlling costs for eGovernment applications and hence planning and controlling economic efficiency, e.g. in a budget process, are carried out by the ITIL Financial Management process. This can also manage the billing of services to customers.

7.1.3 Operative IT Service Management processes (Service Support)

The service quality of eGovernment applications can only be steered in conjunction with the operative side. The IT services are performed on a day-to-day basis by the ITIL Service Support processes.

Service Desk

Effective communication with customers is an efficient precondition for the successful operation of eGovernment applications. This means that customers or users must be provided with quick and simple contact to IT. According to ITIL, this means that a central point of contact, the Service Desk, must be set up in order to bundle communications economically whilst providing ongoing user support. In the case of eGovernment applications, communication with citizens can also take place via the Service Desk. In order to boost acceptance, it should be possible to reach a service desk through a number of different communication paths, such as telephone, email, or web applications.

82 SAGA 4.0

Incident Management

Reports of incidents, as well as general queries, must be collected and promptly handled. The ITIL Incident Management process receives reports from users, responds by ensuring consistent handling with the least possible annoyance for the user, and informs the user of the status of trouble-shooting activities. In order to ensure a high degree of satisfaction among users, trouble-shooting as set forth in the SLA (refer to "Service Level Management" on page 80) is monitored on the basis of the support level and, if necessary, stepped up by way of escalation. Incident management should be supported by software, such as a ticketing system (also referred to as a trouble ticket system), in order to be able to manage messages and communicate these to other processes and also in order to evaluate them. Incident management also includes reports on security incidents and is hence of considerable importance for information security161.

Problem Management

If immediate and clearly identification of incidents and trouble-shooting are not possible, Incident Management can restore the service quickly for the user with a bypass solution. At the same time, however, Incident Management commissions the ITIL Problem Management process to search for the fault. The elimination of the causes of the incident, which can also be carried out proactively, improves the reliability and economic efficiency of IT services.

Configuration Management

The operation of eGovernment applications requires an information basis for all IT service management processes. The ITIL Configuration Management process manages information concerning the properties and relationships of all components of the IT infrastructure. This also includes archiving master copies of the software used. The other ITIL processes can use this information or can also report changes in configuration.

Change Management

Applications, infrastructure, documentation, processes and methods must be modified and amended in order to further develop IT or eliminate the causes of incidents. The ITIL Change Management process is used to steer and control these changes. One key aspect here is agreement among all those involved about the expected effects of the planned changes in a so-called change-release committee (Change Advisory Board, CAB). Release by the CAB is a prerequisite for reducing, to a reasonable level, the risk of endangering the availability of IT services as a result of change conflicts. Changes must be tested and secured through suitable fall-back procedures. A regularly updated change calendar simplifies coordination.

Release Management

Infrastructures are further developed in new releases. The ITIL Release Management process covers the planning, design, generation, configuration, testing, acceptance and

161 Refer to [BSI 2005]

SAGA 4.0 83

putting into operation of a software or hardware version for a production environment. Releases must be planned in line with a version policy, adequately tested prior to release and, in order to secure ongoing operations, taken into production (roll-out) under the control of Change Management. Release Management is linked to IT procurement and to contract managements as described in the KBSt publication series (e.g. "ITIL and IT procurement"162).

7.1.4 IT securityIT security is an important basis for successful eGovernment applications. For this purpose, a separate dedicated publication on Security Management is issued in ITIL which refers to a far-reaching linking of the Security Management process with the IT Service Management processes. Furthermore, with a view to security management, ITIL also refers the BS 7799163 standard by the British Standard Institution; their recommendations are considered as the international standard ISO/IEC 279001 in the BSI's IT-Grundschutz [IT Baseline Protection] in BSI-Standard 100-1.

Generally speaking, the recommendations by the German Federal Office for Information Security (BSI) on the security of eGovernment applications164 and the BSI's IT-Grundschutz [IT Baseline Protection] (former IT-Grundschutzhandbuch [IT Baseline Protection Manual])165 must be taken into consideration here. When planning eGovernment applications, IT security must be included from the very beginning166. In the interest of economic efficiency, IT security measures must be reasonable. A protection requirement report, like the one recommended in BSI-Standard 100-2167 should be drafted as early as possible in order to serve as a basis. Such a protection requirement report classifies the IT infrastructure on the basis of possible damage in the protection requirement categories of normal, high and very high.

When a normal protection requirement for eGovernment applications is found, the standard measures recommend in the IT-Grundschutzkataloge [IT Baseline Protection catalogues] can be used. In the case of high or very high protection requirements, a risk analysis based on BSI-Standard 100-3168 should be additionally carried out with the support of the IT-Grundschutzkataloge [IT Baseline Protection catalogues]. This can be used not just to evaluate the extensively described risks but also to adopt extended measures from the IT-Grundschutzkataloge [IT Baseline Protection catalogues] or additional measures from the E-Government-Handuch169 [eGovernment manual] in order to compensate for higher risks.

The work involved in operating a secure infrastructure may not be economically feasible for smaller public agencies so that it could make sense to outsource this to the computer centres of external IT service providers of higher-level public agencies.

162 Refer to http://www.kbst.bund.de/itil , box 2Produkte & Dokumente" [Products & Documents] > "ITIL und IT-Beschaffung" [ITIL and IT procurement]

163 Refer to http://www.bsi-global.com/164 Refer to the eGovernment manual at: http://www.bsi.bund.de/fachthem/egov/3.htm165 Refer to IT baseline protection catalogues at: http://www.it-grundschutz.de/166 Refer to section 8.1" IT security concept" on page 91167 Refer to http://www.bsi.de/literat/bsi_standard/standard_1002.pdf168 Refer to http://www.bsi.de/literat/bsi_standard/standard_1003.pdf169 Refer to http://www.e-government-handbuch.de/

84 SAGA 4.0

7.2 Design of an eGovernment infrastructure

The purpose of introducing a reference infrastructure in SAGA is to define the infrastructural preconditions necessary for operating eGovernment applications and the required system structure. The following goals are to be achieved in line with the protection requirements by defining parameters for a reference infrastructure in the sense of an operating environment.

a. Suitable physical protection of systems

b. Suitable availability of systems

c. Suitable security of systems and their components

d. Classification of systems and their components according to separate security zones

Figure 7-2: Engineering viewpoint of an eGovernment application

IVBVIVBV Extranet, VPN

Extranet, VPN

Infrastructure

Network

Users / External services

External backup

Dat

a ba

ckup

Man

agem

ent z

one

Information & service zone

Logic & processing zone

Data zone

AccesscontrolAccesscontrol

Accesscontrol

Networkaccess

Accesscontrol

Networkaccess

User

CentralOFA

offering

CentralOFA

offeringCentral

OFAoffering

CentralOFA

offering

Externalspecific

application

Externalspecific

applicationExternalspecific

application

Externalspecific

application

InternetInternet

AccesscontrolAccesscontrol

AccesscontrolAccesscontrol

AccesscontrolAccesscontrol

AccesscontrolAccesscontrol

User

SAGA 4.0 85

e. Scalability of systems and infrastructures

f. Simple service, efficient maintenance and updating of complex systems and their components by operating personnel

Fig. 7-2 on page 84 shows a general overall view of a distributed eGovernment application with the user, network and infrastructure areas.

Both the network and the user areas are typically beyond the control of the operator of an eGovernment application and hence do not form a focal point of interest in this discussion. The infrastructure area, in contrast, is controlled by the operator and must feature a suitable system structure in order to meet the operational requirements for eGovernment applications.

The requirements for a computer centre and its IT infrastructure will be described in the following sections.

7.2.1 Physical infrastructureServers and IT systems must be installed in suitable locations if they are to be protected against force majeure, such as lightning, fire, water, excessively high temperatures, or technical failure, such as power outages, as well as organizational shortcomings, such as unauthorized access to protected rooms. This is why computer centres planning to operate eGovernment applications should use the protection requirement report in order to implement the required IT security measures according to the BSI's IT-Grundschutzkataloge [IT baseline protection catalogues]. These measures include, for instance:

a. Installing IT systems in suitable rooms

b. Controlling access to these rooms

c. Suitable fire detection and fire-fighting systems

d. Suitable power supply systems

e. Suitable air-conditioning systems

f. Data backup according to the related data backup concept

7.2.2 Zone concept and communication relationsThe systems inside the computer centre are located in different zones which are defined on the basis of the relevant safety and security requirements for the services and data of the respective zones. In order to ensure that the zone concept covers the general protection requirements of eGovernment applications, at least the four zones described below should be implemented within a computer centre's infrastructure. Operation of complex eGovernment applications may require additional zones. These zones should be adequately separated according to the basic structures for security gateways170, i.e.:

170 BSI IT baseline catalogues, measure M 2.73, Selecting suitable basic structures for security gateways, http://www.bsi.de/gshb/deutsch/m/m02.htm

86 SAGA 4.0

a. Any network component (router, switch, hub, etc.) can only be used as an interface between one zone and another, so that any network component only passes on data concerning or originating from the two zones directly connected to it. This prevents any mixing up of data streams in the case of a fault or deliberate attack.

b. A server system can host the systems of a single zone only. This means that distributed applications must run on server systems in different zones.

c. A server system with eGovernment applications requiring communication connections to several zones must include a corresponding number of physically and logically separated network connections (e.g. multiple network cards). This system thereby rules out a transition from one zone to another.

Information and services zone

The information and services zone covers that part of the network which is located between the Internet and the other zones of the network. This zone contains servers which can be accessed by external networks or which, for their part, use the services of external networks. Further information zones should be set up if systems with different security levels are to be operated.

In line with protection requirements, communications between the systems of the information and services zone and the systems of the logic and processing zone should be protected by encrypted communication channels.

Logic and processing zone

The systems of this zone process data from the data zone and make such data available to users via systems of the information and services zone. Direct communication between external networks – such as the Internet – and the logic and processing zone is not permitted.

Data zone

The data zone contains all the systems where data is stored and made available for longer periods of time. Access to this zone is permitted from the processing zone and the management zone only. Direct access from external networks is not permitted under any circumstances. In the same way, direct access from this zone to other zones is not permitted. One exception to this is the management zone.

Management zone

The management zone contains all the systems which are needed for administrative purposes or for monitoring systems in other zones. Furthermore, this zone can also contain central user administration or authentication services. Access from the management zone to other zones and vice versa is hence permitted.

Access from within external networks to the management zone is not permitted under any circumstances.

SAGA 4.0 87

Data backup

Every zone should include its own data backup components. Data of the information zones should also be backed up in this case via protected communication channels.

7.2.3 Network access and access controlSecurity gateways control the separation of the individual zones within the computer centre as well as access by and to external networks. Different technologies can be used for these purposes.

The interface between the information and services zone and external networks is the most security-critical point and is hence protected by a combination of multiple security mechanisms. Different network segments and address areas are separated here on the network protocol level. Internal network addresses are masked and are hence not published in external networks. In the case of small networks on an IPv4 basis without a high protection requirement, this can also be carried out with Network Address Translation (NAT).

Furthermore, filter mechanisms are in place in order to ensure that access from external networks is restricted to defined services in the information and services zone. The filter rules are typically implemented on firewalls or firewall routers which screen the information in the headers of the incoming data packages on the basis of package filters and reject unauthorised access attempts.

Furthermore, application gateways can be used which fully isolate communications, validate data streams on the application level and, when necessary, implement a protocol-conforming re-generation of requests.

The communication relations between the internal zones are also controlled by security gateways. In order to adequately control access to the sensitive areas of the logic and processing zone as well as the data zone, firewalls should be used because of their comprehensive filter options. These firewalls work on the basis of dynamic package filters (stateful inspection) and are capable of monitoring not just individual packages but even communication streams involving multiple packages. Dynamic package filters enable the validation of network connections not just on the basis of invariable rules, but additionally even on the basis of historical communication relations.

Thanks to simple and flexible administration, VLAN technology is the system of choice for controlling access to the systems in the management zone. For this purpose, all the systems requiring access to a service in the management zone are combined to form a virtual network segment (VLAN). In order to prevent unwanted communication between the individual zones via the VLANs of the management zone, all the systems are fitted with a second network interface which may not be used for any purposes other than administration and which is fitted with a package filter.

Using VLAN technology for connecting any zones other than the management zone is not recommended for security reasons.

88 SAGA 4.0

7.3 Networks as the link between an infrastructure and external services and users

The network level is the link between the systems of the computer centre infrastructure and external services as well as users of eGovernment applications, refer to Fig. 7-2 "Engineeringviewpoint of an eGovernment application" on page 84. This level also contains the Internet, TESTA (Trans-European Services for Telematics between Administrations), the Informationsverbund der Bundesverwaltung (IVBV) [Federal Administration Information Network], the Informationsverbund Berlin-Bonn (IVBB) [Berlin-Bonn Information Network] as well as other VPN-based networks or extranets. In-house intranets also form part of the network level. Although a clear consolidation trend has been observed in recent years in the field of network technologies, many different technologies are still in use. However, abstraction to higher protocol or application levels can render the system interoperable, so that SAGA does not give concrete technology recommendations for the network level.

From the point of view of the engineering viewpoint of an eGovernment application, however, secure and performant communication with the Internet, TESTA, IVBV, IVBB or extranets has an important role to play in order to ensure reliable access to users and external services. When eGovernment applications are designed, the necessary bandwidths must hence be made available on the basis of an assessment of the anticipated network communication, and the access control mechanisms described in section 7.2.3 must be implemented.

7.4 Access to external servicesExternal services use the infrastructure of eGovernment applications via networks, refer to Fig. 7-2 "Engineering viewpoint of an eGovernment application" on page 84.

7.4.1 Deutsches Verwaltungsdiensteverzeichnis[German Directory of Administrative Services]

The Deutsches Verwaltungsdiensteverzeichnis (DVDV)171 [Germany Directory of Administrative Services] forms a universal infrastructure for eGovernment in Germany. This is where the addressing parameters of the public administration's online services are stored in XML format. These are primarily technical descriptions of the services in WSDL format172 as well as supplementary URLs and cryptographic certificates. The DVDV makes it possible to find all the information required for automated machine-to-machine communication in machine-readable form. This is the basis for fully automated online services between machines which are nevertheless secure and legally binding.

171 Refer to http://www.dvdv.de/172 Web Service Description Language; refer to section 8.7.1.1 "Middleware communication

within the administration” on page 121

SAGA 4.0 89

The LDAP173 directory service standard is the technical basis for this and defines the structure for the storage and retrieval of DVDV information. The core of the DVDV is the central federal master which is provided by the Bundesstelle für Informationstechnik (BIT) [Federal Office for Information Technology], refer to Fig. 7-3. This is the only place where write access to the data stocks is possible. Data updating is carried out by the connected, authorised offices in the federal states. The federal master continuously mirrors its data stock on distributed (e.g. in the federal states) DVDV federal-state servers which share the query load for the individual data retrievals. OSCI transport protects the updating and replication of the WSDL files and the supplementary parameters.

The first application since 1 January 2007 is the implementation of the Framework Act on Registration, which was revised in 2002, especially the part concerning data transmissions between federal states. This makes paper-based responses and updating of the civil register obsolete. Instead, the exchange of data between participating public agencies is exclusively electronic and automated. Other services already integrated (as per mid-2007) are the services of the Federal Central Tax Office for communication with the registration authorities within the scope of issuing uniform tax ID numbers and the municipal core identity register of the Free State of Saxony. The architecture of the DVDV is designed in such a manner that any automated communication relationships in eGovernment can basically use its services.

173 Lightweight Directory Access Protocol, refer to section 8.8.1 “Directory services andregistries“ on page 130; the open source reference implementation OpenLDAP is used for DVDV, refer to http://www.openldap.org

Figure 7-3: Structure of the German Directory of Administrative Services

Agency network /

infrastructure

TESTA network

Other networks / Internet

DVDVupdate client

(per fed. state)

DVDVupdate client

(per fed. state)

Agency 5procedureAgency 5procedure

Agency 4procedureAgency 4procedure

Agency 3procedureAgency 3procedure

Agency 2procedureAgency 2procedure

Agency 1procedureAgency 1procedure

DVDVfederalmaster

DVDVfederalmaster

DVDV-fed. stateserver 2

DVDV-fed. stateserver 2

DVDVfed. stateserver 1

DVDVfed. stateserver 1

DVDVfed. stateserver n

DVDVfed. stateserver n

Clearinghouse AClearinghouse A

Clearinghouse BClearinghouse B

90 SAGA 4.0

BIT operates the coordination office of the DVDV. This secures the flow of information to users and service providers. Queries can be sent to the DVDV via the e-mail address: dvdv@bva.bund.de.

7.4.2 Use of OFA offersWithin the scope of the federal administration's one-for-all offers (OFA offers)174 – broken down into OFA services, OFA systems, OFA concepts and infrastructures – offers that can be used by public agencies to integrate their eGovernment applications are made available via the Internet and via the IVBV.

Services, such as the ePayment OFA service175, can be accessed via the web service interfaces on the Internet. For this purpose, the OFA service provides the web service interfaces required at the server end along with a reference implementation for accessing the web services by the relevant eGovernment application. Communication with external special applications of other public agencies or enterprises proceed in a similar manner; middleware communication interfaces may be used for these purposes too.

De-centralized OFA offers, on the other hand, such as the OFA data security systems176 and the form management system177, are implemented within the computer centre infrastructure of the different public agencies. The rules already described in section 7.2 "Design of an eGovernment infrastructure" on page 84 should be observed in this case too.

174 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76175 Refer to OFA service - Payment platform ("ePayment"): http://www.kbst.bund.de/efa-zvp176 Refer to OFA system - Data security ("virtual post office") http://www.kbst.bund.de/efa-vps177 Refer to OFA system - Form Management System: http://www.kbst.bund.de/efa-form

SAGA 4.0 91

8 Technology viewpoint: Standards for IT architecture and data security

In this chapter, technical standards are assigned to the individual elements of the architecture model introduced in chapter 3. Furthermore, this chapter also provides brief descriptions of these technical standards. If no version numbers of standards are stated, the version which is most stable from a market point of view should be used, even though this is not necessarily the latest version.

The meaning of the classifications "Mandatory", "Recommended" and "Under observation" are described in more detail in section 2.3.1 "Classification in SAGA" on page 20.

8.1 IT security conceptThe standards for IT security presented recommend a system approach in order to achieve and maintain a suitable level of IT security. For this purpose, an IT security concept will be drafted and further-developed in an IT security management process which will be continuously operated following its initiation. Since December 2005, the Germany Federal Office for Information Security (BSI) has recommended and supported an approach in several BSI-Standards and the IT-Grundschutzkataloge [IT baseline catalogues] which was previously presented in the IT-Grundschutzhandbuch (IT-GSHB) [IT Baseline Protection Manual].

8.1.1 Management systems for information securityThe first step towards a comprehensive IT security concept requires the creation of a management system for information security.

Mandatory: BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS) v1.0 [BSI standard 100-1: Management systems for Information Security]

BSI standard 100-1178 with the general requirements for an ISMS (information security management system) should be applied within the scope of the security concept. The standard is fully compatible with ISO standard 27001 and also considers the recommendations of ISO standards 13335 and 17799179.

8.1.2 IT baseline protection approachIn the interest of the economic efficiency of the IT security concept, only those IT security measures must be adopted for the IT application and the data to be processed which are

178 Refer to http://www.bsi.de/literat/bsi_standard/standard_1001.pdf179 Refer to http://www.iso.org/

92 SAGA 4.0

suitable for the protection requirement identified. The system approach for the IT concept involves steps such as the protection requirement analysis.

Mandatory: BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise v1.0[BSI standard 100-2: IT baseline protection approach]

In December 2005, the German Federal Office for Information Security (BSI) published its "BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise"180 [BSI standard 100-2: IT baseline protection approach]. The standard describes how IT security management can be set up in practice and operated. It should be used within the scope of the IT security concept. With this approach, IT security concepts can be created, simply and efficiently, whilst IT security can be maintained and improved in ongoing operations.

8.1.2.1 Protection aims

Protection aims define the security interests of communication partners in a general form:

a. Confidentiality – protection against disclosure to unauthorized parties:No data is made available or disclosed to unauthorized individuals, entities or processes.Confidentiality is ensured by encrypting the information (cryptography).

b. Integrity – protection against manipulation:Unauthorized modification or destruction of data is not possible. This includes information concerning the origin or time of creation.Integrity is ensured by encrypting the information (cryptography) or by the use of signatures.

c. Availability – protection against failure of IT systems:The properties of an entity and/or resource can be accessed and/or used when this is desired by an authorized entity.A high degree of availability is achieved through multiplicity, distribution and error tolerance.

8.1.2.2 Protection requirement categories

The protection requirements must be identified for each IT application of the data processed. These requirements are a function of the potential damage that can be caused by impairment of the IT application in question with regard to the protection aims defined in section 8.1.2.1.

A protection requirement category can be assigned to every protection aim in order to evaluate applications from a security point of view. In "BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise" [BSI standard 100-2: IT baselines protection approach], the following classification is hence made:

180 Refer to http://www.bsi.de/literat/bsi_standard/standard_1002.pdf

SAGA 4.0 93

Protection requirement categories

"Normal" The impact of loss or damage is limited.

"High" The impact of loss or damage may be considerable.

"Very high" The impact of loss or damage can reach catastrophic proportions and could threaten the very existence of the agency/company.

Table 8-1: Protection requirement categories

One particular aspect which must be considered when determining protection requirements is whether personal data is processed in order to ensure that data protection laws are adhered to. SAGA does not explain any data protection measures. The E-Government-Handbuch [eGovernment manual] (module: Datenschutzgerechtes E-Government181 [Data-protection-compliant eGovernment]) contains data protection information with regard to frames of reference, challenges and recommended actions.

8.1.3 Risk analysis

Mandatory: BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz v2.0 [BSI-Standard 100-3: Risk analysis on the basis of IT baseline protection]

BSI standard 100-3182 for additional risk analysis following the IT baseline protection analysis should be applied to areas with security requirements that go a long way beyond what is normally required. The reasons for a risk analysis could be a high or very high security requirement, the use of applications or components not (yet) addressed in the IT Baseline Protection Catalogues, as well as the operation of application scenarios (environment, application) not considered in IT baseline protection.

8.1.4 Implementation of the security concept

Mandatory: Industrial Signature Interoperability Specification – MailTrusT (ISIS-MTT) v1.1.

ISIS-MTT v1.1183 specifies fundamentals, standards and profiles for implementing security concepts. This specification was the result of the merger of the Industrial Signature Interoperability Specification (ISIS) and MailTrusT (MTT).

ISIS-MTT is a delta specification which is based on existing, relevant international standards (S/MIME, PKIX, PKCS, X.509, ETSI, CEN ETSI) and which defines these in precise detail for use in practical application. The specification focuses on conformance requirements which must be fulfilled by compliant PKI components and applications during the generation and processing of certain data objects, such as certificates.

The ISIS-MTT specification chiefly consists of a kernel document which is exclusively based on the profiling (restriction of optional characteristics) of international standards and which is hence expected to ensure interoperability on an international scale. This core

181 Refer to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter II, module "Data-protection-compliant eGovernment"

182 Refer to http://www.bsi.de/literat/bsi_standard/standard_1003.pdf183 Refer to http://www.isis-mtt.org/

94 SAGA 4.0

specification is mandatory for all manufacturers and suppliers and can be supplemented by optional profiles as required. The "SigG Profiles" and "Optional Enhancements to the SigG-Profile" already available describe the current status of qualified signatures in Germany.

The kernel document of the ISIS-MTT specification consists of eight parts with the following contents:

1. Establishing public-key certificates, attribute certificates and certificate revocation lists

2. Setting up and sending requests to the certification authority (PKCS#10) and replies from the certification authority (PKCS#7)

3. Setting up encrypted and signed messages

4. Requests for public-key certificates, attribute certificates and certificate revocation lists using LDAP, OCSP184, FTP or HTTP; setting up queries and responses to and from timestamp units

5. Validity check for public key certificates and attribute certificates

6. Approved algorithms for hash functions, signatures, encryption, authentication of messages to and from the certification authority; approved algorithms for XML Signature and XML Encryption

7. Description of the "Cryptographic Token Interface" (PKCS#11) with data types and functions

8. Profiling and expanding XML signatures and XML encryption

Mandatory: BSI, IT-Grundschutz-Kataloge [IT Baseline Protection Catalogues]

The BSI's IT-Grundschutz-Kataloge185 [IT Baseline Protection Catalogues] should be applied and the standard security measures described there should be implemented. The use of module, measure and risk catalogues supports a component-orientated work approach with which IT security concepts can be implemented easily, efficiently and effectively.

Recommended: KoopA ADV, Handlungsleitfaden für die Einführung der elektronischen Signatur und Verschlüsselung in der Verwaltung v1.1[Guideline for the Introduction of the Electronic Signature and Encryption in the Administration]

The Handlungsleitfaden für die Einführung der elektronischen Signatur und Verschlüsselung in der Verwaltung [Guideline for the Introduction of the Electronic Signature and Encryption in the Administration] issued by the KoopA ADV186 is designed to facilitate solutions to cryptographic problems for selected projects in the public administration, and is hence primarily devised as a working aid for public agencies. Typical problems and tasks are defined in the form of scenarios for which potential solutions are identified and described.

184 OCSP = Online Certificate Status Protocol185 Refer to http://www.bsi.de/gshb/deutsch/186 Refer to http://www.koopa.de/projekte/pki.html

SAGA 4.0 95

Recommended: BSI, E-Government-Handbuch [eGovernment manual]

The BSI E-Government-Handbuch187 [eGovernment manual] contains organizational and technical recommendations concerning the use of IT in eGovernment applications. When it comes to developing an eGovernment application within the meaning of SAGA, the security-related recommendations contained in the manual are particularly relevant188. The chapter on "IT und IT-Sicherheit" [IT and IT security] contains security recommendations in the following modules:

1. General information on secure eGovernment applications

2. Authentication in eGovernment

3. Optimization of web content retrieval

4. Secure integration of eGovernment applications

5. Secure payment methods for eGovernment

6. Secure communication in eGovernment

7. Secure client-server architectures for eGovernment

8. eGovernment without active content

The recommendations of the E-Government-Handbuch [eGovernment manual] should always be taken into consideration especially when a protection requirement category is "high" or "very high"189 – i.e. when the requirements for IT security go beyond the scope of IT baseline security. The E-Government-Handbuch [eGovernment manual] provides recommendations here for the design and implementation of a corresponding level of IT security.

8.2 Process models

8.2.1 Technologies for process modelling

Mandatory: Role models and flow charts

Role models and flow charts should be used to define simple processes. All the roles and systems related to a process must be identified, and the process steps must be described in the form of flow charts. In a broader sense, flow charts should be orientated towards DIN 66001: "Informationsverarbeitung, Sinnbilder und ihre Anwendung" [Information processing, symbols and their use].

187 Refer to http://www.bsi.bund.de/fachthem/egov/3.htm188 Refer to http://www.bsi.bund.de/fachthem/egov/6.htm#Kapitel_IV, sub-chapter IV B: "IT

and IT security"189 Refer to section 8.1 "IT security concept" on page 91

96 SAGA 4.0

Mandatory: Unified Modeling Language (UML) v. 2.0

The Unified Modeling Language (UML)190 should be used for object-orientated modelling in the preparation and documentation of large projects. Use cases and activity diagrams are a particularly tried-and-tested way of creating and co-ordinating transparent specifications. These specifications can be reused with the respective tools.

8.2.2 Interchange formats for process models

Recommended: XML Metadata Interchange (XMI) v2.x

XML Metadata Interchange (XMI)191 is a standard of the Object Management Group (OMG) which should be used in XML for the notation and interchange of Meta Object Facility (MOF)-based models (example: UML). This format is open and manufacturer-independent. UML 2.0192 can be transformed to XMI 2.0 and XMI 2.1. XMI v2.0.1 was standardized as ISO/IEC 19503:2005193 .

8.3 Data models

8.3.1 Technologies for data modelling

Mandatory: Entity Relationship Diagram (ERD)

Entity Relationship Diagrams should be used when developing relational database schemas. Functional data models for a special rough concept should also be presented using ER diagrams.

Mandatory: Unified Modeling Language (UML) v. 2.0

UML should be used in data modelling for object-orientated applications. Class diagrams, for instance, are the approach of choice and can also be used in other applications or by other tools. XML data structures can be directly generated from the corresponding specifications.

8.3.2 Interchange formats for data models

Mandatory: XML Schema Definition (XSD) v1.0

XML schemas according to the World Wide Web Consortium (W3C)194 should be generated using the XML Schema Definition (XSD) for the structured description of data.

190 Refer to http://www.uml.org/191 Refer to http://omg.org/technology/documents/formal/xmi.htm192 Refer to section 8.2.1 "Technologies for process modelling" on page 95193 Refer to http://www.iso.org/194 Refer to http://www.w3.org/XML/Schema

SAGA 4.0 97

Recommended: Regular Language Description for XML New Generation (Relax NG)

The ISO standard (ISO/IEC 19757-2:2003195) Relax NG196 can, just like the XML Schema Defini­tion (XSD), be used for the structured description of data.

Relax NG is less widespread than XSD and has less tool support. However, it is simpler, easier to read and yet more expressive.

Although XSD is mandatory for the structured description of data, the use of Relax NG is still possible because Relax-NG schemas can be transformed to XML schemas using (Open Source) tools197.

Recommended: XML Metadata Interchange (XMI) v2.x

Analogous to section 8.2.2 "Interchange formats for process models" on page 96.

8.3.3 Description language for metadata of files

Recommended: Resource Description Framework (RDF)

Resource Description Framework (RDF)198 is a language for presenting information about resources on the web that was developed by W3C. RDF is designed to describe metadata and ontologies and hence forms an important part of Semantic Web. RDF makes it possible to declare vocabulary, i.e. to define terms, so that the relevant information about resources is described in such a manner that it can be gathered, integrated and reused. Simple vocabulary, such as Dublin Core, can also be used in RDF. RDF should be used to describe metadata for web resources.

Recommended: Dublin Core (DC)

Dublin Core (DCMI Metadata Terms)199 is a widely used standard which was standardized by ISO200 and NISO201. The standard is a development of the Dublin Core Metadata Initiative (DCMI). The latest version was standardized by NISO in May 2007 – the revision is still based on the ISO 15836-2003 standard from February 2003. This standard should be used for the metadata description of websites, digital objects and documents.

The second chapter of the specification ("The Dublin Core Metadata Element Set") contains the 15 core elements of the standard: contributor, coverage, creator, date, description, format, identifier, language, publisher, relation, rights, source, subject, title and type. Each element corresponds to a property and a certain value can be assigned to each property. They are optional and can be used as often as required to describe an object. Other sub-

195 Refer to http://www.iso.org/196 Refer to http://www.relaxng.org/197 Refer to http://www.thaiopensource.com/relaxng/trang.html198 Refer to http://www.w3.org/TR/rdf-primer/199 Refer to http://dublincore.org/documents/dcmi-terms/200 Published as ISO 15836:2003, refer to http://www.iso.org/201 Published as ANSI/NISO Z39.85 - 2007, refer to http://www.niso.org/standards/index.html

98 SAGA 4.0

elements – called "refinements" or "qualifiers" – are available for certain elements, and enable a more precise description of resources.

The elements of Dublin Core can be used in HTML/XHTML and RDF/XML documents. In HTML documents, Dublin-Core metadata can be stated with the META element in the document header.

8.4 Application architectureThis section defines programming languages and technologies for implementing the application architecture. The first part defines standards for the middleware of the eGovernment architecture module with special emphasis on the aspect of application integration. This is followed by an extension of the standards to cover applications without middleware or with a low middleware share, respectively, so that the middleware standards can also be used for simpler applications.

The specifications and recommendations are based on the design principles of operating-system neutrality, interoperability and portability.

Middleware services – such as replication, distributed transaction management, personalization, internationalization, messaging, etc. – are referenced in the current version to a certain extent.

Deviations from preferred technologies (i.e. mandatory, recommended technologies) are acceptable in justified cases, for example, in the case of significant economic advantages.

8.4.1 Application architecture with middleware

Mandatory: Java Platform, Enterprise Edition (Java EE) v5

Technologies of the Java Platform, Enterprise Edition (JavaEE)202 should be used to develop and integrate the following applications (integrated applications) on the middle tier:

a. one-for-all offers (OFA offers)203,

b. applications which directly integrate basic components or libraries provided for this purpose, and

c. applications designed, as a whole or in part (components), for re-use (porting).

Java EE is a specification which defines several programming interfaces and a development process. Java EE in its entirety constitutes an architecture that considers and supports major aspects of business-critical applications. Java EE already offers important function modules which can be used to develop applications. Since version 1.4204, these also include standard programming interfaces (APIs) and technologies as so-called core libraries: Java Authentication and Authorization Service (JAAS), Java API for XML Parsing (JAXP) and Java Naming and Directory Interface (JNDI). All the core libraries should be given preference over alternative technologies.

202 Refer to http://java.sun.com/javase/203 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76204 Published as JSR-000151, refer to http://www.jcp.org/en/jsr/detail?id=151

SAGA 4.0 99

The difference between Java EE v5205, which was finalized in May 2006, and its predecessor J2EE v1.4 can be found especially in the upgrading capacity of applications and the simplification of the programming model. Enhancements were also made, for instance, to the definition and use of web services and the mapping of Java classes to XML and databases.

Compared to Java SE v5, Java EE v5 offers the following APIs and technologies as so-called optional libraries:

a. Java Message Service (JMS) v1.1

b. J2EE Connector Architecture (JCA) v1.5

c. Java Transaction API (JTA),

d. JavaMail API v1.4,

e. Java Management Extensions (JMX) v1.2,

f. Enterprise JavaBeans (EJB) v3.0206,

g. Java Server Faces (JSF) v1.2207,

h. Java Server Pages (JSP) v2.1, and

i. Java Servlet API v2.5.

Thanks to the Java Community Process208, more and more application-near elements will increase the diversity of Java EE in the near future. New elements are defined via so-called Java Specification Requests (JSR).

Mandatory: Java Platform, Standard Edition (Java SE) v5

If an application does not require full Java EE functionality, neither initially nor on a permanent basis, Java EE technologies should be used individually as an alternative solution. The basis for this is the Java 2 platform as the Standard Edition (Java SE)209. The individual technologies should be used in accordance with Java EE specification 5210 in order to create a compatible migration path to Java EE.

Under observation: C# Language Specification/ Common Language Infrastructure (CLI)

The ECMA-334211 "C# Language Specification" standard (ISO/IEC 23270:2006212) specifies the form and the interpretation of programmes which were written in C# language.

205 Published as JSR-000244, refer to http://www.jcp.org/en/jsr/detail?id=244 and http://java.sun.com/javaee/

206 Instead of using EJB, another application framework can also be used, such as the Spring Application Framework, refer to http://www.springframework.org/

207 Published as JSR-000252, refer to http://www.jcp.org/en/jsr/detail?id=252208 Refer to http://www.jcp.org/209 Refer to http://java.sun.com/javase/210 Published as JSR-000176, refer to http://www.jcp.org/en/jsr/detail?id=176211 Refer to http://www.ecma-international.org/publications/standards/Ecma-334.htm212 Refer to http://www.iso.org/

100 SAGA 4.0

The ECMA-335213 "Common Language Infrastructure (CLI)" standard (ISO/IEC 23271:2006 and ISO/IEC TR 23272:2006214) defines an infrastructure for different system environments in which applications can be executed which were written in different programming languages. The infrastructure abstracts from specific properties of the system environments so that applications do not have to be changed in order to run them on different systems.

There are two implementations of the ECMA standard. .NET-Framework from Microsoft runs under Windows only. The two ECMA standards are based on .NET v2.0 and are hence also part of .NET v3.0. A further implementation, called Mono215, ensures availability for further operating systems.

The two ECMA standards do not form a complete development framework because they do not support, for instance, the implementation of clients and presentation layers.

Under observation: Business Process Execution Language for Web Services (BPEL4WS) v1.1

BPEL4WS216 can be used to compose business processes on the basis of web services. BPEL4WS, which is under the patronage of OASIS, is an XML-based description language which supplements web services and the related standards (SOAP, WSDL, UDDI) with business transactions.

Major infrastructure and application suppliers support the specification. Furthermore, tools, including Open-Source solution217, are provided. BPEL4WS was developed further to the OASIS standard WS-BPEL 2.0.

Under observation: Web Services Business Process Execution Language (WS-BPEL) v2.0

WS-BPEL218 v2.0 was adopted by OASIS in April 2007 as the standard. The standard is used to compose business processed based on web services. Tools for WS-BPEL v2.0 are commercially available. WS-BPEL v2.0 is not compatible with its predecessor BPEL4WS v1.1.

8.4.2 Application architecture without middlewareIn addition to the standards discussed in the previous section, the following technology is also available for simple eGovernment applications without middleware.

Recommended: PHP Hypertext Preprocessor (PHP) v5.x

PHP219 (recursive acronym for "PHP: Hypertext Preprocessor") can be used for applications without an integration requirement, i.e. non-distributed, stand-alone applications which

213 Refer to http://www.ecma-international.org/publications/standards/Ecma-335.htm214 Refer to http://www.iso.org/215 Refer to http://www.mono-project.de/216 Refer to http://www-128.ibm.com/developerworks/library/specification/ws-bpel/217 Refer to http://www.bpelsource.com/products/218 Refer to http://www.oasis-open.org/specs/index.php#wsbpelv2.0219 Refer to http://www.php.net/

SAGA 4.0 101

do not communicate with one-for-all offers (OFA offers)220 with legacy systems or with other eGovernment special applications. PHP is developed as an open-source project by the PHP Group and represents a script language embedded in HTML for developing web applications.

Version 5 features comprehensive support for object-orientated programming concepts. Procedures for data encapsulation, referencing of variables and exception handling mark important progress within the scope of further development.

8.5 ClientThe client is a software on a terminal device which makes use of a service offered by middleware. The client tier includes both the classical user site with all the options state-of-the-art technology has to offer in order to interact with public administrations, with access to information possible via different media. In Germany, the following media are currently the most popular, so that optimum conditions for the widespread use of eGovernment applications will exist if the information on offer is tailored to these devices:

a. Computers (PCs, notebooks)

b. Mobile phones / personal digital assistants (PDAs)

c. External systems (e.g. ERP systems of industrial companies)

Standardization efforts for game consoles and, in particular, for digital interactive TV have not yet resulted in uniform recommendations. The so-called "thin client" seems to be the most promising device in terms of public acceptance. Thin clients come with very low-profile hardware and software and require the server to provide as much functionality as possible.

8.5.1 Access to information with computersTwo different clients are generally available on computers221 in order to access or receive information: web browser and specific client applications (e.g. Java clients, also Applets). The latter, for instance, permit direct access to Internet-based services, e-mail servers and – depending on authorization – to the operating system in order to use local resources, such as local data volumes. Whenever active contents are used, no client technologies other than those permitted in SAGA may be used. The use of Active-X-Controls is generally not permitted. When active contents are used, a parallel offer without active contents should also be available, if possible; refer also to section 1.5 "Basic principles for eGovernmentapplications" on page 13.

220 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76221 A device is referred to as a computer in this context if the device does not have a small

display, has no low bandwidth and has a keyboard.

102 SAGA 4.0

Mandatory: Java Network Launching Protocol (JNLP) v1.5

Java client applications should be delivered via the Internet using the Java Network Launching Protocol (JNLP)222. In this case, the "Java Web Start"223 reference implementation can be used.

The use of JNLP enables the simple, platform-independent distribution of Java applications and avoids version conflicts with Java Runtime Environments (JREs).

8.5.1.1 Web browsers

In order to enable wide-spread use of the eGovernment applications on offer, web browsers should be used as the front-end device and these should be capable of processing and presenting the presentation-tier formats (refer to section 8.6). The following browser-based client technologies are permitted in this context:

a. The use of cookies is permitted on condition thati. these are not persistent, andii. websites of a domain do not include contents of other domains which set cookies.The recommendations for the HTTP protocol according to section 8.7.5 must be taken into consideration in this context.

b. The use of Javascript is permitted, however, it must be ensured that the websites can still be used even if Javascript was deactivated. This demand corresponds to BITV224 which is classified as mandatory. This ensures that the user is not forced to lower his/her security settings due to eGovernment applications. Section 8.6.4 "Active contents" on page 108 must be taken into consideration when Javascript is used.

c. The use of Java Applets is permitted if these are signed by the server and can hence be identified by the client as authentic and non-corrupted. Manufacturers of Java Applets must subject their products to quality assurance, preferably by an independent software company, or must at least warrant the quality of their products in a declaration of quality.225

d. Plug-ins are used exclusively according to the requirements listed on the website: http://www.kbst.bund.de/saga-plugins .

e. Configuration examples are prepared for customary browser types and made available by BSI on the Internet.

f. The confidentiality of form data must be ensured by the use of TLS-encrypted channels and the pertinent server certificates.

222 Published as JSR-000056 (Final Release), refer to http://www.jcp.org/en/jsr/detail?id=56223 Refer to http://java.sun.com/products/javawebstart/224 Refer to BITV, section 6.3 "It must be ensured that documents created using markup

languages can be used if scripts, applets or other programmed objects are deactivated." (http://bun desrecht.juris.de/bitv/ )

225 Further information on this subject can be found on the web at: http://www.kbst.bund.de/saga-applets.

SAGA 4.0 103

g. The statutory instrument (ordinance) on barrier-freedom remains fully applicable to the use of permitted client technologies.

8.5.1.2 Client applications

The web browser is the standard client for applications with direct access to web servers. Client applications can be used if direct access to Internet-based services is not necessary, or if the functionality of a web browser must be reasonably seen to be inadequate, for example, in the case of complex business transactions with direct file system access or use of legacy software. These applications are installed on the client computer and must be updated as required by technical progress. Updates can be made available on CD-ROM or as signed applications for downloading226 from a website. The use of Java applications is recommended (advantage: platform independence).

Client applications must meet with the following requirements:

a. Any personal and security-critical data is stored in encrypted form on the local data medium.

b. In the case of direct access to Internet-based services, secure data transmission to the server is supported, refer to section 8.7.5 "Application protocols" on page 126. No protocols other than those defined in section 8.7.1 "Middleware communication" on page 121 are permitted for other client/server communications.

c. The formats documented in SAGA for exchanging user data with other applications should be supported.

d. A manufacturer-independent software company assures the quality of the application.

e. The application is supplied along with a software certificate which is verified during the course of the installation.

f. Besides an option to download the application from the Internet, distribution on CD-ROM is also offered.

g. The statutory instrument (ordinance) on barrier-freedom must be taken into consideration.

8.5.1.3 E-mail client

The e-mail clients used to receive, send and process e-mails must at least ensure technical support for the e-mail standards referred to in section 8.7.3 "E-mail communication". Note that communication of these clients is standardized with regard to communication with public administrations only and/or restricted to the above. With regard to the use of external mail servers not connected to federal institutions, the client is not subject to any restrictions whatsoever in terms of the standards and protocols used.

8.5.2 Access to information with mobile devicesContrary to the computer, mobile phones, PDAs and other mobile devices feature either

226 Refer also to "Java Network Launching Protocol (JNLP) v1.5" on page 102

104 SAGA 4.0

a. a small display,

b. low bandwidth, or

c. no standard keyboard

and must support the standards offered by servers for mobile devices of the presentation tier227. Furthermore, the standards, which are generally described for the presentation of contents by computers, should also be fulfilled as comprehensively as possible by the mobile devices228.

The requirements concerning active contents described in section 8.5.1 "Access toinformation with computers" on page 101 must be observed.

8.5.3 Access to information via external systemsCommunication and interaction between external and internal systems should be handled via a subset of the standards defined for communication and interaction between internal systems. In this respect, XML via SOAP is considered to be equivalent to RMI with regard to server-to-server communication229.

8.5.4 Technologies for authenticationIn order to ensure that the protection aims of confidentiality and integrity are achieved, certain eGovernment applications require the identification and authentication of communication partners.

Mandatory: BSI, E-Government-Handbuch, module: "Authentisierung im eGovernment" [eGovernment manual, module: Authentication in eGovernment]

Different authentication mechanisms can be adopted in this context, e.g. user identification / password, PIN / TAN or certificates. The "Authentisierung im eGovernment"230 [Authentication in eGovernment] module of the E-Government-Handbuch [eGovernment manual] issued by BSI addresses different authentication methods with a view to aspects of technical security.

Recommended: Security Assertion Markup Language (SAML) v2.0

SAML231 is an XML-based format for exchanging authentication information. The exchange of data in a uniform format especially supports interoperability between eGovernment applications. Version 2.0 was published in March 2005.

227 Refer to section 8.6.13 "Technologies for presentation on mobile devices" on page 119228 Refer to section 8.6 "Presentation" on page 105229 Refer to section 8.6.6 "Interchange formats for data " on page 109, section 8.4 "Application

architecture" on page 98, section 8.7 "Communication" on page 121 and section 8.8 "Backend" on page 130

230 Refer to the eGovernment manual (http://www.bsi.bund.de/fachthem/egov/6.htm), chapter IV B, module "Authentication in eGovernment"

231 Refer to http://www.oasis-open.org/specs/index.php#samlv2.0

SAGA 4.0 105

Under observation: Kerberos v5

Kerberos232 is a protocol for authentication in computer networks that was developed by the Massachusetts Institute of Technology (MIT). Interoperability is supported through the uniform exchange of authentication data. However, operating-system dependent expansions do sometimes lead to incompatibilities between different implementations.

8.6 PresentationThe presentation tier provides information to the clients. Depending on the given application, different formats must be made available. These are listed in the following sections. The use of open interchange formats which offer a sufficient number of functions and which are available on different platforms is generally required.

It is permitted to offer the information in addition - or, if so agreed to by all the parties involved, even as an alternative - to the mandatory and recommended formats using formats not considered within the scope of SAGA.

8.6.1 Barrier-free presentation

Mandatory: Barrierefreie Informationstechnik Verordnung (BITV)[Barrier-free information technology ordinance]

In order to make the Internet accessible as a source of information to disabled people too, the avoidance of barriers for people with disabilities is requested. In order to ensure this kind of barrier-free presentation, the requirements of the "Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie Informationstechnik Verordnung – BITV)"233 [Ordinance on the creation of barrier-free information technology pursuant to the law on equal opportunities for the disabled (barrier-free information technology ordinance – BITV)] are to be adhered to. This statutory instrument implements section 11 of the "Behindertengleichstellungsgesetz" [Equal Opportunities for Individuals with Disabilities Act] and, in particular, considers the Web Content Accessibility Guidelines234 of W3C, version 1.0. Concerning the barrier freedom issue, refer also to section 5.4.3 on page 62.

232 Published as RFC 1510, refer to http://www.ietf.org/rfc/rfc1510.txt und http://web.mit.edu/kerberos/

233 Refer to http://bundesrecht.juris.de/bitv/ 234 Refer to http://www.w3.org/TR/WCAG10/

106 SAGA 4.0

8.6.2 Character sets

Mandatory: Unicode v4.x UTF-8

In order to provide a sufficient number of characters for the different letters, numbers and symbols used world-wide, the character set used for documents should be ISO 10646:2003235 (also known as Unicode v4.x) in UTF-8 encoding236.

Recommended: Unicode v4.x UTF-16

If documents are written in a non-west European language (e.g. Greek, Bulgarian), ISO 10646:2003237, also known as Unicode v4.x, in UTF-16 encoding238 can be used.

8.6.3 Technologies for information processing

Mandatory: Hypertext Markup Language (HTML) v4.01

HTML is the established language for publishing hypertext on the World Wide Web. In addition to the text, multimedia and hyperlink functions of earlier HTML versions, HTML v4.01239 supports more multimedia options, script languages and improved forms and print functions. The use of HTML v4.01 is necessary for the technical implementation of 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 internationalization of documents in an effort to make the World Wide Web truly world-wide.

Mandatory: Multipurpose Internet Mail Extensions (MIME) v1.0

The Multipurpose Internet Mail Extensions (MIME) format should be used for the standardized definition of the format of a file or any part thereof. It enables the e-mail client or the web browser to unambiguously identify the file type, refer to RFC 2045 to RFC 2049240. The official list of possible manifestations of MIME types can be found at the Internet Assigned Numbers Authority (IANA)241.

235 Refer to http://www.iso.org/ 236 This specification is available at http://www.unicode.org/ 237 Refer to http://www.iso.org/ 238 This specification is available at http://www.unicode.org/. 239 Refer to http://www.w3.org/TR/html401/, standardized as ISO/IEC 15445:2000, refer to

http://www.iso.org/240 Refer to http://www.ietf.org/rfc.html241 Refer to http://www.iana.org/assignments/media-types/

SAGA 4.0 107

Mandatory: Java Servlet v2.5

Servlet v2.5242 should be used for the dynamic generation of web contents. Servlet v2.5 makes it possible for application servers to accept and send a dynamic response to client queries on the basis of Java EE 5.

Mandatory: Java Server Pages (JSP) v2.1

JSP v2.1243 should be used for the dynamic, server-based generation of web contents. JSP v2.1 contains an Expression Language (EL) which is used to separate the Java Code from the JSP Code and to embed it in statistical fragments (e.g. HTML). JSP v2.1 is based on Java Servlet v2.5 technology.

Recommended: Extensible Hypertext Markup Language (XHTML) v1.0

XHTML v1.0 Second Edition, a W3C recommendation244 from August 2002, is an exchange format (reformulation of HTML v4.0 whilst maintaining conformance to XML) which meets with a host of requirements concerning interoperability and barrier freedom. The use of XHTML v1.0 speeds up the development of websites because, in contrast to HTML v4.01, many previously required browser optimizations are no longer necessary. Furthermore, clear, syntactical specifications (lower case for elements and attributes, well-formed according to XML) significantly boost the readability of the source code and hence the cost of its maintenance and further development. XHTML 1.0 is supported by all customary browsers.

Recommended: Cascading Style Sheets Language Level 2 (CSS2)

Cascading Style Sheets Language Level 2 (CSS2)245 should be used to design HTML pages.

Recommended: Extensible Stylesheet Language (XSL) v1.0

Extensible Stylesheet Language (XSL)246, version 1.0, should be used for the server-based, dynamic transformation and presentation of XML documents, for instance, in HTML files.

Recommended: Extensible Stylesheet Language Transformations (XSLT) v1.0

If applications use different XML schemas, conversion from one format to another can become necessary for data interchanging purposes. This format conversion operation should be carried out using the XSLT247 language defined by W3C as part of XSL (Extensible Stylesheet Language).

242 Published as JSR-000154 (Maintenance Release), refer to http://www.jcp.org/en/jsr/detail?id=154

243 Published as JSR-000245, refer to http://www.jcp.org/en/jsr/detail?id=245244 Refer to http://www.w3c.org/TR/xhtml1245 Refer to http://www.w3.org/TR/REC-CSS2/246 Refer to http://www.w3.org/TR/xsl/247 Refer to http://www.w3.org/TR/xslt

108 SAGA 4.0

Under observation: Extensible Stylesheet Language (XSL) v1.1

XSL v1.1 has been a W3C recommendation since 5 December 2006248. A number of new features were introduced with this version, for instance, the referencing of page numbers, bookmarks as well as change marks. Compared to its predecessor version, XSL v1.0, tool support and the relevance of the practical application of the standard are not as advanced.

Under observation: Extensible Stylesheet Language Transformations (XSLT) v2.0

Extensible Stylesheet Language v2.0 was adopted in January 2007 as a W3C recommendation249. It offers many new features, such as the use of XPath 2.0. Other enhancements include the output methods, as well as sorting and grouping options. XSLT v2.0 does not come with full downward compatibility. Moreover, few processors are available up to now.

8.6.4 Active contentsActive contents are computer programs which are contained on websites (e.g. JavaScript) or which are automatically reloaded when a page is viewed (e.g. Java Applets, ActiveX Controls or flash animations) and which are executed on the client (by the browser or by the operating system). When active contents are used, the restrictions described in section 8.5 must be taken into consideration.

Mandatory: ECMAScript Language Specification

In as far as Javascript is used within HTML pages according to section 8.5.1.1 "Web browsers" on page 102, this must conform to the ECMA-262 specification, 3rd Edition250 dated December 1999. This specification was also adopted by ISO/IEC as a standard under the name ISO/IEC 16262251.

8.6.5 Forms

Under observation: XForms v1.0

XForms is a specification252 for web forms. The aim of this specification is to replace the forms implemented in HTML or XHTML. XForms offers a wider range of functions and in the case of client-end processing leads to a reduction in the amount of server access.

Although implementations and also plug-ins are available, not all browsers support XForms by default.

248 Refer to http://www.w3.org/TR/xsl11/249 Refer to http://www.w3c.org/TR/xslt20/250 Refer to http://www.ecma-international.org/publications/standards/Ecma-262.htm251 Refer to http://www.iso.org/252 Refer to http://www.w3.org/TR/xforms/

SAGA 4.0 109

8.6.6 Interchange formats for data

Mandatory: Extensible Markup Language (XML) v1.0

XML v1.0253 is a language derived from the Standard Generalized Markup Language (SGML) which should be used for structured data description. The language enables extension and the addition of tags. The data shown is presented in Extensible Stylesheet Language (XSL)254.

XML should serve as the universal and primary standard for the interchange of data between all the information systems relevant for administrative purposes.

New systems to be installed should be capable of exchanging data using XML. Existing systems do not necessarily have to be XML-enabled, however, they should aim to be able to exchange XML data using adapters (integration components).

Under observation: Election Markup Language (EML) v4.0

Standard Election Markup Language (EML)255 can be used especially in order to exchange data in the environment of eVoting processes.

EML v4.0 was adopted in February 2006 as the OASIS standard. This language defines a series of XML schemas which are suitable and which implement a generic election process. These election processes can include public elections (general elections, municipal elections) or private elections (works council elections, secret ballots). EML can be adapted to all scenarios and also supplies security functions for data backup.

Under observation: Extensible Markup Language (XML) v1.1

XML v1.1256 is a revised version of XML v1.0 and was published on 4 February 2004 in "Recommended" status and amended on 15 April 2004. Its Unicode capabilities have been improved and inconsistencies in line end markings have been eliminated. There are currently almost no parsers for XML v1.1.

8.6.7 Exchange formats for documents

8.6.7.1 Formats for text documents for exchanging information

Text documents used to exchange information should only be read by the target group and should not be changed. This is why no further editing is foreseen.

253 Refer to http://www.w3.org/XML/254 Refer to "Extensible Stylesheet Language (XSL) v1.0" on page 107255 Refer to http://www.oasis-open.org/specs/index.php#eml4.0256 Refer to http://www.w3.org/TR/xml11/

110 SAGA 4.0

Mandatory: Portable Document Format (PDF) v1.4

Adobe's platform-independent Portable Document Format should be used for text documents where no further editing is foreseen and to support forms and barrier-free text documents. PDF version 1.4257 is supported by Acrobat Reader258 , version 5 and higher.

If this format is used, the recommendations of the "Sicherer Internet-Auftritt im E-Government" [Secure Internet Presence] module of the eGovernment manual must be considered with regard to active content259. Especially when it comes to converting (partially) blackened text to PDF format, it must be ensured that the text can in fact no longer be copied / searched for in PDF. Similarly, the PDF password function, irrespective of the key strength of encoding, is not a sufficient security measure for documents with content that needs to be protected, because this function can be bypassed using the appropriate tools.

Mandatory: Hypertext Markup Language (HTML)

Hypertext documents used to exchange information, e.g. newsletters, should be used in HTML260 format, refer to section 8.6.3 "Technologies for information processing" on page 106.

Recommended: Portable Document Format (PDF) v1.5

PDF version 1.5261 is the successor to PDF v1.4, which was classified as "Mandatory". For older versions of Windows and MacOS, there are at times no distributions of Acrobat Reader for PDF v1.5 available. PDF version 1.5 is supported by Acrobat Reader262, version 6 and higher. This version also features extensions in the areas of cryptography, compression and content-related tagging. If this format is used, the recommendations of the "Sicherer Internet-Auftritt im E-Government" [Secure Internet Presence] module of the eGovernment manual must be considered with regard to active contents263.

Under observation: Portable Document Format (PDF) v1.6

PDF version 1.6264 is currently used to a very limited extent only. This version is the successor to version 1.4, which was classified as "Mandatory" and to version 1.5, which was classified as "Recommended". It features enhancements in the areas of cryptography and the embedding of file attachments. PDF version 1.6 is supported by Acrobat Reader265, version 7 and higher. If this format is used, the recommendations of the "Sicherer Internet-Auftritt im

257 Refer to http://www.adobe.com/devnet/pdf/pdfs/PDFReference.pdf258 Refer to http://www.adobe.de/products/acrobat/readermain.html259 Refer to http://www.bsi.bund.de/fachthem/egov/download/4_IntAuf.pdf260 Standardized as ISO/IEC 15445:2000, refer to http://www.iso.org/261 Refer to http://www.adobe.com/devnet/pdf/pdfs/PDFReference15_v6.pdf262 Refer to http://www.adobe.de/products/acrobat/readermain.html263 Refer to http://www.bsi.bund.de/fachthem/egov/download/4_IntAuf.pdf264 Refer to http://www.adobe.com/devnet/pdf/pdfs/PDFReference16.pdf265 Refer to http://www.adobe.de/products/acrobat/readermain.html

SAGA 4.0 111

E-Government" [Secure Internet Presence] module of the eGovernment manual must be considered with regard to active contents266.

8.6.7.2 Formats for text documents for further processing

It must be possible to edit text documents which are foreseen for further processing. A distinction is made between simple text documents and complex text documents containing layout information.

Mandatory: Text

Simple, mostly non-structure text documents which are foreseen for further processing and which have no layout requirements should be exchanged in the widely used text format (e.g. with the .txt file extension) in order to ensure that these are generally readable. The character sets to be used are laid down in section 8.6.2.

Recommended: Open Document Format for Office Applications (OpenDocument) v1.0

OpenDocument267 was standardized by OASIS as an XML-based document format for texts, spreadsheets, presentations and other Office documents. The contents of the document are separate from the information about its layout and can be processed independent of each other. OpenDocument can be used to exchange complex documents that are foreseen for further processing. In November 2006, OpenDocument v1.0 was published as a standard under the name ISO/IEC 26300:2006268. OpenDocument is supported, for instance, by the platform-independent, license-free and open Office package from OpenOffice.org269.

Under observation: Office Open XML (OOXML)

As an XML-based document format for texts, spreadsheets, presentations and other Office documents, Office Open XML270 was published by ECMA in December 2007 as the ECMA-376 standard. It can be used to exchange complex documents which are to be processed further.

8.6.7.3 Formats for spreadsheets for exchanging information

Spreadsheets used to exchange information should only be read by the target group and should not be changed. This is why no further editing is foreseen.

Mandatory: Portable Document Format (PDF) v1.4

Analogous to section 8.6.7.1 on page 109.

266 Refer to http://www.bsi.bund.de/fachthem/egov/download/4_IntAuf.pdf267 Refer to http://www.oasis-open.org/committees/download.php/12572/OpenDocument-v1.0-

os.pdf268 Refer to http://www.iso.org/269 Refer to http://de.openoffice.org/ 270 Refer to http://www.ecma-international.org/publications/standards/Ecma-376.htm

112 SAGA 4.0

Recommended: Portable Document Format (PDF) v1.5

Analogous to section 8.6.7.1 on page 109.

Under observation: Portable Document Format (PDF) v1.6

Analogous to section 8.6.7.1 on page 109.

8.6.7.4 Formats for spreadsheets for further processing

It must be possible to edit spreadsheets which are foreseen for further processing. A distinction is made between simply structured data and complex documents, even with layout information.

Mandatory: Comma Separated Value (CSV)

Tables with simple structure data without layout requirements should be exchanged using Comma Separated Values271 (file extension: .csv).

Under observation: Open Document Format for Office Applications (OpenDocument) v1.0

Refer to section 8.6.7.2 on page 111. OpenDocument272 supports the referencing of formula languages, however, these do not form part of the standard. An OASIS Technical Committee is working on a suitable specification273.

Under observation: Office Open XML (OOXML)

Analogous to section 8.6.7.2 on page 111.

8.6.7.5 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: Portable Document Format (PDF) v1.4

Analogous to section 8.6.7.1 on page 109.

271 Published as RFC 4810, refer to http://www.ietf.org/rfc/rfc4180.txt272 Standardized as ISO/IEC 26300:2006, refer to http://www.iso.org/273 Refer to http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office-formula

SAGA 4.0 113

Mandatory: Hypertext Markup Language (HTML)

Presentations that cannot be changed which are available in hypertext document format should be exchanged in HTML274 format, refer to section 8.6.3 "Technologies forinformation processing" on page 106.

Recommended: Portable Document Format (PDF) v1.5

Analogous to section 8.6.7.1 on page 109.

Under observation: Portable Document Format (PDF) v1.6

Analogous to section 8.6.7.1 on page 109.

Under observation: Synchronized Multimedia Integration Language (SMIL) v2.0

SMIL is an XML-based, standardized language for writing interactive multimedia presentations275. "A typical example of such an application is a multimedia news centre which plays audios and videos to a message whilst background information is displayed at the same time on HTML websites."276

There is a host of free SMIL players. Of the browsers currently available on the market, up to now only the Internet Explorer supports a subset of SMIL277.

8.6.7.6 Formats for presentations for further processing

It must be possible to edit presentations which are foreseen for further processing.

Under observation: Open Document Format for Office Applications (OpenDocument) v1.0

Analogous to section 8.6.7.2 on page 111.

Under observation: Office Open XML (OOXML)

Analogous to section 8.6.7.2 on page 111.

8.6.7.7 Secured document exchange

The "communication" interaction stage requires the exchange of secure documents. This includes, for example, securing documents as e-mail attachments as well as securing documents for all kinds of communication paths.

274 Standardized as ISO 15445:2000, refer to http://www.iso.org/275 Refer to http://www.w3.org/TR/2005/REC-SMIL2-20050107/276 Refer to Pauen, Peter: Zukunftsorientierte Ansätze – SMIL [Future-orientated approaches –

SMIL] http://www.informatik.fernuni-hagen.de/pi3/ PDFs/SMIL.pdf 277 Refer to http://www.w3.org/AudioVideo/#SMIL

114 SAGA 4.0

The ISIS-MTT v1.1 standard is relevant with regard to securing e-mail attachments whilst XML Signature and XML Encryption as XML-specific standards are relevant for the secure exchange of XML documents (e.g. for forms designed for further processing).

Mandatory: Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 3

ISIS-MTT v1.1 defines an interoperable data interchange format for signed and encrypted data. It also considers the securing of binary data (in particular, Part 3: Message Formats), so that secured transmission of all kinds of files as e-mail attachments is possible.

Mandatory: XML Signature

The joint W3C and IETF standard XML Signature (XML Signature Syntax and Processing, W3C Recommendation and IETF RFC 3275)278 describes digital signatures for all kinds of data (however, usually XML) by providing an XML schema and a set of processing rules (for generating and validating the signature). The signature can cover one or more documents and/or different kinds of data (pictures, text, etc.).

One central feature of XML Signature is that it is possible to sign specific parts of an XML document only rather than the entire document. Thanks to this flexibility, it is, for example, possible to secure the integrity of certain elements of an XML document whilst other parts can be edited. For instance, a user can fill in certain parts of a signed XML form without violating the integrity of the document. This was not possible with conventional signatures because the complete document was always signed, so that any change / addition would have meant a violation of its integrity.

Mandatory: XML Encryption

The W3C standard XML Encryption (XML Encryption Syntax and Processing, W3C Recom­mendation)279 provides an XML schema and a set of processing rules which support the encryption/decryption of entire documents, including XML documents, XML elements and contents of XML elements.

Together with XML Signature, XML Encryption is the foundation for several standards accepted in the industry for secure XML-based document exchange (Web Services Security, SAML, ISIS MTT, ebXML-Messaging, FinTS, OSCI-Transport).

Under observation: XML Advanced Electronic Signatures (XAdES) v1.2

The "XML Advanced Electronic Signatures (XAdES)"280 standard was developed by the European Telecommunications Standard Institute (ETSI). XAdES signatures not only fulfil the requirements of the advanced electronic signature under the EU Directive, they also warrant additional non-repudiation and long-term validity. XAdES is an extension of XML Signature.

278 Refer to http://www.w3.org/TR/xmldsig-core/279 Refer to http://www.w3.org/TR/xmlenc-core/280 Refer to http://www.w3.org/TR/XAdES/

SAGA 4.0 115

In Germany, XAdES is used, for instance, by Deutsche Post's Signtrust. There are several commercial suppliers of programs which process documents for storage on the basis of XAdES.

8.6.8 Interchange formats for graphics

Mandatory: Graphics Interchange Format (GIF) v89a

In view of its widespread use, Graphics Interchange Format (GIF)281 should be used to exchange graphics and diagrams. GIF graphic files are compressed with a colour depth of 256 colours (8 bits per pixel.

Mandatory: Joint Photographic Experts Group (JPEG)

The Joint Photographic Experts Group282 (JPEG) format should be used to exchange photographs. This format supports changes in the compression factor and the definition of density, so that a compromise between file size, quality and use is facilitated. JPEG can be used to store colour and grey-value images with 16.7 million colours (24-bit colour information). This format is supported by a host of graphic and presentation programs. Conventional compression in JPEG results in losses, however, it does achieve high compression rates. JPEG is not suitable for graphics with similar colour surfaces and strongly contrasting colour transitions (example: characters).

Recommended: Portable Network Graphics (PNG) v1.2

The Portable Network Graphics283 (PNG) format can be used. This format is license-free. It supports 16 million colours, transparency, loss-free compression, incremental display of graphics (beginning with the gross structure until the file is completely transmitted) and the identification of damaged files. The format was standardized by ISO (ISO/IEC 15948:2003284).

Recommended: Tagged Image File Format (TIFF) v6.0

TIFF285 can be used for saving bit-mapped graphics. TIFF is supported by all conventional graphic and presentation programs. In order to achieve maximum interoperability, the properties of the "Baseline TIFF"286 must be used exclusively. TIFF can be used when the format must be capable of presenting documents consisting of several pages. TIFF is

281 Refer to http://www.w3.org/Graphics/GIF/spec-gif89a.txt282 Refer to http://www.jpeg.org/index.html?langsel=de , standardized as ISO/IEC 10918-1:1994,

refer to http:// www.iso.org/ , standardized as ITU-T.81, refer to http://www.itu.int/rec/T-REC-T.81/en

283 Refer to http://www.w3.org/TR/PNG/284 Refer to http://www.iso.org/285 Refer to http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf286 "Baseline TIFF" compiles the properties of TIFF files which should support each program

with TIFF capability. For instance, the two compression methods "Huffmann" and "Packbits" belong exclusively to "Baseline TIFF" whilst "LZW", "JPEG", "ZIP" and "CCITT" are optional extensions which are not implemented in every program with TIFF capability.

116 SAGA 4.0

particularly suitable for scanned text documents (b/w graphics or graphics with grey shades).

Recommended: Geo Tagged Image File Format (GeoTIFF)

GeoTIFF287 is an extension of TIFF v6.0. A geo-reference is additionally featured in the file header so that contrary to conventional TIFF, the geo-reference file *.tfw does not have to be created. The GeoTIFF format is supported by established geo-information systems.

Under observation: Joint Photographic Experts Group 2000 (JPEG2000) / Part 1

JPEG 2000288 is the successor to JPEG and is not yet widely used. Offering the same quality, it features higher compression than JPEG. Together with the use of metadata, JPEG 2000 is suitable for recording geo-data289. Browser support for JPEG 2000 is only available using plug-ins. Classification of JPEG 2000 is limited to the first part of the ISO standard290 because this contains the core functionality and is the most useful standard.

8.6.9 Animation

Mandatory: Animated Graphics Interchange Format (Animated GIF) v89a

Animation means moving features in graphics displayed on a website. Animated GIF, a variant of GIF graphic format291 should be the product of choice here. With this format, several individual GIF images are stored in a file, with the possibility to define their sequence, display time and number of repetitions.

8.6.10 Audio and video data

8.6.10.1 Interchange formats for audio and video files

Recommended: Quicktime

The customary Quicktime format292 should be used to exchange video sequences. A suitable plug-in enables a web browser to "play" such files.

Recommended: MPEG-4 Part 14 (MP4)

MP4 is the official container format for MPEG-4 which was developed by the Moving Picture Experts Group and standardized as ISO/IEC-14496293. MP4 is known as part 14 of the MPEG-4

287 Refer to http://www.remotesensing.org/geotiff/288 Refer to http://www.jpeg.org/jpeg2000/289 Refer to OGC: "GML in JPEG 2000 Interoperability Experiment (GMLJP2)",

http://www.opengeospatial.org/ stan dards/gmljp2 290 Standardized as ISO/IEC 15444-1:2004, refer to http://www.iso.org/291 Refer to http://www.w3.org/Graphics/GIF/spec-gif89a.txt292 Refer to http://quicktime.apple.com/293 Refer to http://www.iso.org/

SAGA 4.0 117

standard. MP4 is an open, manufacturer-independent standard and this format is supported by many tools and products on different platforms.

MP4 can be used to exchange video files although MPEG-4 should be used as codec.

Recommended: Ogg Encapsulation Format (Ogg)

Ogg294 is an open, manufacturer-independent container format for audio and video files. It is developed by the Xiph.org Foundation295 and is supported by many media players.

With the Ogg container format, different codes can be used depending on the application in question. Theora296 can be used for video data. Speex297 is suitable for audio files with low quality requirements, for example, voice recordings. Vorbis298, which features a quality that is equivalent to MP3, can be used for audio files with normal quality requirements. Loss-free Audio-Codec FLAC299 can be used for cases where maximum quality is required.

Under observation: Windows Media Video (WMV) v9

The quality of Windows Media Video (WMV) format is better than that of Quicktime format. However, patents make the use of WMV format difficult for open source developers.

Under observation: RealMedia v10

RealMedia from RealNetworks300 is the container format for the RealAudio audio format and the RealVideo video format. All these formats are proprietary. The quality of RealVideo exceeds that of the Quicktime format. The free player is available for all conventional platforms as well as some mobile devices. RealMedia should only be used if the audio-video data is not to be archived. It is ensured that the files can be played today, however, with a view to the future, it must be feared that no more players will be available for what will be then old RealMedia formats.

8.6.10.2 Interchange formats for audio and video streaming

In contrast to "normal" audio and video sequences, audio and video streaming offers a format that enables playing already during transmission. This enables live transmission of videos, whereas "normal" audio and video files must be completely transmitted first before they can be started. This area is occasionally characterized by a slightly confusing mix of suppliers, products, container and content formats. Since SAGA does not intend to recommend products, recommendations will be given for the container format only.

What is important here is that the recommendations should be compatible - to the maximum extent possible – with customary streaming servers and client products. Due to

294 Published as RFC 3533, refer to http://www.ietf.org/rfc/rfc3533.txt295 Refer to http://www.xiph.org/ogg/296 Refer to http://www.theora.org/297 Refer to http://www.speex.org/298 Refer to http://www.vorbis.com/299 Refer to http://flac.sourceforge.net/300 Refer to http://www.realnetworks.com/

118 SAGA 4.0

the fact that this area has been a field of strong competition for several years, the different products are currently highly compatible in terms of the formats supported.

Mandatory: Hypertext Transfer Protocol (HTTP) v1.1

In order to reach as many citizens as possible, the server product selected should enable the transport of streaming data via HTTP301.

Recommended: Quicktime

In order to achieve the maximum possible degree of compatibility between the streaming signal and commonly used web browsers and video clients and/or plug-ins, Quicktime format302 should be used, refer to section 8.6.10.1 on page 116.

Recommended: MPEG-4 Part 14 (MP4)

MP4 can be used to stream video sequences. In this case, MPEG-4 should be used as the codec, refer to section 8.6.10.1 on page 116.

Recommended: Ogg Encapsulation Format (Ogg)

Ogg303 is an open, manufacturer-independent container format that can be used to stream audio and video.

For information concerning suitable audio and video codecs, refer to section 8.6.10.1 "Interchange formats for audio and video files" on page 116.

Under observation: Windows Media Video (WMV) v9

Analogous to section 8.6.10.1 on page 116.

Under observation: RealMedia v10

Analogous to section 8.6.10.1 on page 116.

When RealMedia is used to stream applications, it must also be considered that the prices for the RealMedia servers, called Helix servers, are high compared to Windows Media Quicktime. However, the Helix Universal servers also support Windows Media and Quicktime.

8.6.11 Interchange formats for geo-informationThe standards listed below for exchanging geo-information are used in the geo-services in section 8.7.6 on page 128.

301 Published as RFC 2616, refer to http://www.ietf.org/rfc/rfc2616.txt, further information available under "HTTP" in section 8.7.5 "Application protocols" on page 126

302 Refer to http://quicktime.apple.com/303 Published as RFC 3533, refer to http://www.ietf.org/rfc/rfc3533.txt

SAGA 4.0 119

Recommended: Geography Markup Language (GML) v3.1.1

GML304 is a markup language used to interchange and save geographical information in vector format which considers spatial and non-spatial properties. This specification was carried out by the Open Geospatial Consortium (OGC)305. GML does not contain any information concerning presentation on the screen or in a map.

GML v3.1.1 should be used especially in conjunction with the use of Web Feature Service (WFS), v1.1, refer to section 8.7.6 "Geo-services" on page 128.

Recommended: Geography Markup Language (GML) v2.1.2

GML v2.1.2 should be used especially in conjunction with the use of Web Feature Service (WFS), v1.0, refer to section 8.7.6 "Geo-services" on page 128.

8.6.12 Data compressionCompression systems should be used in order to enable the interchange of large files and minimize network load.

Mandatory: ZIP v2.0

Compressed data should be exchanged in the internationally used ZIP306 version 2.0 format.

Recommended: Gnu ZIP (GZIP) v4.3 / Tape ARchive (TAR)

In order to compress large file archives, the formats GZIP (file extension: .gz), version 4.3, specified in RFC 1952307, and TAR can be used. The TAR header file is part of POSIX.1-2001 that is included in ISO/IEC standard 9945308.

In order to create a file archive, all the files must first be compiled with TAR to form an archive file. The archive file can then be compressed with GZIP (file extension: .tgz or .tar.gz). In contrast to file archives compressed with ZIP, this so-called solid compression leads to smaller file sizes because redundant information is compressed across file borders.

8.6.13 Technologies for presentation on mobile devicesIn the event that an information offering for mobile phones and PDAs is to be developed, preference should be given to SMS services because these are widely accepted by citizens. The presentation of websites for mobile communications is not yet widely used in Germany.

304 Refer to http://www.opengeospatial.org/specs/, published as ISO/PRF 19136, refer to http://www.iso.org/

305 Refer to http://www.opengeospatial.org/306 Refer to http://www.pkware.com/business_and_developers/developer/popups/appnote.txt307 Refer to http://www.ietf.org/rfc/rfc1952.txt308 Refer to http://www.iso.org/

120 SAGA 4.0

In addition to the following technologies, the standards which were generally described for presenting contents on computers should also be used for mobile devices, refer to sections 8.6.1 to 8.6.12.

Mandatory: Short Message Services (SMS)

The Short Message Service (SMS)309 is part of the GSM mobile communication standard (Global System for Mobile communication) which is being prepared by the 3rd Generation Partnership Project (3GPP). 3GPP combines several standardization committees (including ETSI) and aims to draft technical specifications which precisely describe all aspects of mobile communication technology.

Under observation: Wireless Application Protocol (WAP) v2.0

The Wireless Application Protocol (WAP)310 v2.0 is a specification for the development of applications that use wireless communication networks. Its main application is mobile communications. WAP includes the Wireless Markup Language (WML) v2.0. Compared to its predecessor version, the presentation possibilities of WAP v2.0 have become much more similar to those on the World Wide Web. With conventional web browsers, it is not possible to read WML pages. This means that offers which are to be provided for mobile Internet applications and for the normal Internet have to be published twice.

WAP v2.0 also contains XHTML Mobile Profile (XHTMLMP)311 which is based on XHTML Basic. This means that documents which were written in XHTML Basic can be read with WAP-2.0 browsers. XHTMLMP supports various script languages, for example ECMAScript Mobile Profile (ESMP), a subset of ECMA262312 without extensive computing and memory script functions.

The majority of mobile devices meanwhile feature WAP 2.0 browsers. However, in the case of mobiles phones, in general, and PDAs, in particular, there is a growing trend towards web browsers with full functionality.

Under observation: Extensible Hypertext Markup Language (XHTML) Basic v1.0

XHTML Basic v1.0313 is a standard for presenting HTML pages converted to XML for applications which do not support the full presentation functionality of HTML (e.g. mobile phone or PDAs).

XHTML Basic was expanded to XHTML Mobile Profile (XHTMLMP)314 which is contained in WAP v2.0. This means that documents which were written in XHTML Basic can be read with WAP-2.0 browsers.

309 Published as 3GPP TS 23.040, refer to http://www.3gpp.org/ftp/Specs/html-info/23040.htm , and published as ETSI TS 123 040 V7.0.1, refer to http://www.etsi.org/

310 Refer to http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html311 Refer to http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-

20011029-a.pdf312 Refer to section 8.6.4 "Active contents" on page 108313 Refer to http://www.w3.org/TR/2000/REC-xhtml-basic-20001219/314 Refer to http://www.openmobilealliance.org/tech/affiliates/wap/wap-277-xhtmlmp-

20011029-a.pdf

SAGA 4.0 121

8.7 CommunicationWithin the "communication" element, a distinction is made between application, middleware and network protocols as well as directory services.

8.7.1 Middleware communicationIn the case of middleware communication, a distinction is made between server applications that communicate within an administration, refer to section 8.7.1.1, and client applications outside the administration which communicate with an administration server, refer to section 8.7.1.2.

The data elements to be transmitted should be specified using the technologies described in section 8.3 "Data models" on page 96 and section 8.6.6 "Interchange formats for data " on page 109.

8.7.1.1 Middleware communication within the administration

Mandatory: Remote Method Invocation (RMI)

Java RMI315 is particularly suitable for internal communications between Java objects. Via RMI, an object on a Java Virtual Machine (VM), can trigger methods of an object that runs on another Java VM. Java Remote Method Invocation is part of the Java 2 Standard Edition (Java SE) and hence also part of the Enterprise Edition (Java EE).

Mandatory: Simple Object Access Protocol (SOAP) v1.1

SOAP316 should be used for communications between the party supplying the server and the user of a server within the meaning of the SOA reference model317. SOAP can be used to exchange structured data as XML objects between applications or their components via an Internet protocol (e.g. via HTTP).

Mandatory: Web Services Description Language (WSDL) v1.1

The Web Services Description Language (WSDL) should be used for service definition purposes. WSDL is a standardized language318 that describes web services in such a manner that they can be used by other applications without the need to know further details of the implementation or to use the same programming language.

Mandatory: Java Message Service (JMS) v1.1

JMS319 is used to generate, send, receive and read messages. JMS API defines a uniform interface that enables Java programs to communicate messages to other massaging

315 Refer to http://java.sun.com/rmi/316 Refer to http://www.w3.org/TR/soap11/317 Refer to Fig. 6-2 on page 69318 Refer to http://www.w3.org/TR/wsdl319 Published as JSR-000914, refer to http://www.jcp.org/en/jsr/detail?id=914

122 SAGA 4.0

systems. The advantage of communication with messages is the loose link. JMS ensures that the messages are sent in an asynchronous and reliable manner.

JMS should then be used when components communicating with each other are not to be disclosed with a view to their interfaces (easier exchangeability) and when communication between the components is to be generally asynchronous and error-tolerant.

Mandatory: J2EE Connector Architecture (JCA) v1.5

JCA320 should be used to integrate existing systems into Java applications and/or to communicate with them. This means that the systems must provide so-called resource adapters. A resource adapter must be created just once for each legacy system and can then be reused in all environments for Java Enterprise Editions (Java EE). The JCA resource adapter frequently uses messages, such as JMS, in order to communicate with legacy systems.

Recommended: Java Language Mapping to OMG IDL

The most well-known implementation of the Java Language Mapping to OMG IDL321 specification, which was published by OMG, is Remote Method Invocation over Internet Inter ORB Protocol (RMI-IIOP) from Sun.

Java RMI-IIOP322 is an integral part of Java Standard Edition (Java SE) and hence also part of the Enterprise Edition (Java EE). Distributed Java applications can communicate via RMI-IIOP with remote applications via CORBA. RMI-IIOP communication can be carried out with all Object Request Brokers which conform to the latest CORBA specification 2.3.1323. The remote applications are hence not limited to the Java language.

Recommended: Web Services (WS) Security v1.1

WS-Security324 is an OASIS standard for secure web services. It defines upgrades of the SOAP protocol in order to provide and ensure confidentiality, integrity and the binding effect of SOAP messages for securing web services. WS-Security supports the signing and encryption of SOAP messages based on XML Signature and XML Encryption. The use of different security models and different cryptographic method must be possible.

WS-Security also enables different "security tokens", i.e. data formats which warrant specific identities or properties, e.g. X.509 certificates, Kerberos Tickets, SAML tokens or encrypted keys.

The specification of WS-Security consists of the "WS-Security Core Specification 1.1" and the following profiles:

a. Username Token Profile 1.1

b. X.509 Token Profile 1.1

320 Published as JSR-000112, refer to http://www.jcp.org/en/jsr/detail?id=112321 Refer to http://www.omg.org/docs/ptc/00-01-06.pdf322 Refer to http://java.sun.com/products/rmi-iiop/323 Refer to http://omg.org/cgi-bin/doc?formal/99-10-07324 Refer to http://www.oasis-open.org/specs/index.php#wssv1.1

SAGA 4.0 123

c. SAML Token profile 1.1

d. Kerberos Token Profile 1.1

e. Rights Expression Language (REL) Token Profile 1.1

f. SOAP with Attachments (SWA) Profile 1.1

The token profiles specify how the different tokens can be used in SOAP.

Under observation: Universal Description, Discovery and Integration (UDDI) v2.0

The UDDI protocol is the basis for designing a standardized, interoperable platform that permits the simple, fast and dynamic search for web services. The further development of UDDI is being promoted within the scope of OASIS325. UDDI is based on standards issued by the W3C and the Internet Engineering Task Force (IETF), such as XML, HTTP, DNS and SOAP.

8.7.1.2 Middleware communication with applications outside the administration

Web services should be used for access by client applications via the Internet to server applications at administrations.

By providing a web service layer for an existing server application, client systems are enabled to trigger the functions of the applications via the Hypertext Transfer Protocol (HTTP). A web service is a service which can be made up of components and which uses SOAP to communicate with other components via the HTTP standard protocol. XML is used for the message content itself. XML was already described in section 8.3 "Data models" on page 96 as a universal and primary standard for exchanging data between all the information systems relevant for administrative purposes.

The Web Service Interoperability Organization (WS-I) defines profiles of existing standards in order to facilitate the compilation of the required standards. The profile to be applied is WS-I-Basic v1.1326 and includes XML Schema v1.0, SOAP v1.1, WSDL v1.1 and UDDI v2.0.

Mandatory: Simple Object Access Protocol (SOAP) v1.1

Analogous to section 8.7.1.1 on page 121.

Mandatory: Web Services Description Language (WSDL) v1.1

Analogous to section 8.7.1.1 on page 121.

Recommended: Web Services (WS) Security v1.1

Analogous to section 8.7.1.1 on page 121.

325 Refer to http://www.uddi.org/326 Refer to http://www.ws-i.org/Profiles/BasicProfile-1.1.html

124 SAGA 4.0

Under observation: Universal Description, Discovery and Integration (UDDI) v2.0

Analogous to section 8.7.1.1 on page 121.

8.7.2 Network protocols

Mandatory: Internet Protocol (IP) v4

The federal administration's IT environment currently uses IP v4 (RFC 791327, RFC 1700328) in conjunction with TCP (Transmission Control Protocol, RFC 793329) and UDP (User Datagram Protocol, RFC 768330).

When new components of a system are to be introduced, these new components should support both IP v4 and IP v6 in order to enable future migration.

Mandatory: Domain Name System (DNS)

Since the mid-1980s, the Domain Name System (DNS, RFC 1034331, RFC 1035332) has been the standard on the Internet. DNS refers to a hierarchical name server service at central points of the Internet. This is where a server name entered is converted to the pertinent IP address.

Under observation: Internet Protocol (IP) v6

IP v6333 is the next version of the IP protocol which up to now has not been very widely used. One of the changes compared to the current version 4 is the extension of the IP address to 128 bits in order to permit addressing of multi-embedded and mobile IP-based systems in future.

IP v6 includes IPsec (IP-Security Protocol) which is chiefly used in the VPN (Virtual Private Network) area and which can also be used independent of IP v6. Thanks to the use of VPNs with secure encryption methods, the transport channel and the authentication of terminal systems is ensured in the manner required, for instance, for wireless networks (Wireless Local Area Network – WLAN) and also for home offices or in site networking. Information on IPsec and VPN is available, for instance, from the German Federal Office for Information Security334.

327 Refer to http://www.ietf.org/rfc/rfc791.txt328 Refer to http://www.ietf.org/rfc/rfc1700.txt329 Refer to http://www.ietf.org/rfc/rfc793.txt330 Refer to http://www.ietf.org/rfc/rfc768.txt331 Refer to http://www.ietf.org/rfc/rfc1034.txt 332 Refer to http://www.ietf.org/rfc/rfc1035.txt333 Refer to http://www.ietf.org/rfc/rfc2460.txt und http://www.ietf.org/rfc/rfc3041.txt 334 Refer to http://www.bsi.de/, e.g. "Aufbau von Virtual Private Networks (VPN) und

Integration in Sicherheitsgateways" [Establishment of Virtual Private Networks (VPNs) and integration into security gateways] at http://www.bsi.de/fachthem/sinet/loesungen_transport/VPN.pdf

SAGA 4.0 125

8.7.3 E-mail communication

Mandatory: Simple Mail Transfer Protocol (SMTP) / Multipurpose Internet Mail Extensions (MIME) v1.0

E-mail protocols that comply with the SMTP / MIME335 specifications for exchanging messages (RFC 2821, RFC 2045 to RFC 2049)336 are required for e-mail transport.

E-mail attachments should correspond to the file formats defined in section 8.6 on page 105.

Mandatory: Post Office Protocol (POP) v3 / Internet Message Access Protocol (IMAP) v4rev1

In exceptional cases, it may be necessary to offer electronic mailboxes. In this case, POP3337 or IMAP338 should be used as the commonly used standards.

Mandatory: Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 1 to Part 6

The secure exchange of e-mails is one possible application for the "communication" interaction stage. Secure e-mail communication includes securing e-mails during their transmission from a sender to a recipient. This application looks at e-mails in their entirety. Section 8.6.7.7 "Secured document exchange" on page 113 discusses the procedures for securing documents, including e-mail attachments.

Taking the basic functions of the electronic signature, encryption and authentication, the ISIS-MTT specification considers a host of applications for processes to secure electronic business (for example, file, mail, transaction and time "protection"), refer to section 8.1.4 "Implementation of the security concept" on page 93.

Parts 1 to 6 are especially relevant for securing e-mail communications.

8.7.4 IP telephonyVoice or telephony is an important and established channel of communication for citizens, business and public agencies. Public agencies are also already running call centres and sometimes make use of telephone systems with Voice-over-IP (VoIP). With this form of communication, the interfaces in the field of presentation must be offered to the outside world and the interfaces in the backend with eGovernment applications must be made available (Computer Telephony Integration – CTI). This means that context-related VoIP connections to the respective specialized officers or call-centre employees can be offered to customers on websites and data received is displayed to the employee without media inconsistencies.

335 Refer to section 8.6.3 "Technologies for information processing" on page 106336 Refer to http://www.ietf.org/rfc.html337 Published as RFC 1939, refer to http://www.ietf.org/rfc/rfc1939.txt338 Published as RFC 3501, refer to http://www.ietf.org/rfc/rfc3501.txt

126 SAGA 4.0

Recommended: H.323

The protocol for signalling according to the ITU-T's standard H.323339 together with the protocols that belong to this family should be used to transport data for IP telephony.

Under observation: Session Initiation Protocol (SIP) v2.0

SIP is a standard for signalling with IP telephony (RFC 3261340) which was drawn up by IETF. It can be used together with the supplementary protocols for data transmission as an alternative to H.323.

8.7.5 Application protocolsSection 8.1.4 "Implementation of the security concept" on page 93 deals with the connection of security-related infrastructures (e.g. directory services for certificates, revocation lists, etc).

Mandatory: File Transfer Protocol (FTP)

File Transfer Protocol (FTP, RFC 959341) is considered the standard for file transfer. FTP is one of the oldest Internet services. FTP enables the shared use of files, it offers users standardized user interfaces for different file system types, and transfers data in an efficient and reliable manner. FTP is typically somewhat faster than HTTP when larger files are to be downloaded.

Since FTP does not encrypt any data, including passwords, before sending, it should not be used for applications with a high security requirement. In such cases, secured methods, such as SSH-2 and TLS, which are also described in this section, must be used.

Mandatory: Hypertext Transfer Protocol (HTTP) v1.1

HTTP v1.1 (RFC 2616342) should be used for communications between the client and web server. However, web servers should also support HTTP v1.0 (RFC 1945343) in addition to version 1.1. The HTTP State Management Mechanism (RFC 2965344) standard should be adopted when HTTP Session Management and cookies are used. In contrast to version 1.0, the upload and download functionality of HTTP v1.1 offers the option of so-called "web folders" (refer to WebDAV on page 128). Chat systems can initiate the reloading of websites via HTTP v1.1.

339 Refer to http://www.itu.int/rec/T-REC-H.323/en340 Refer to http://www.ietf.org/rfc/rfc3261.txt341 Refer to http://www.ietf.org/rfc/rfc959.txt342 Refer to http://www.ietf.org/rfc/rfc2616.txt343 Refer to http://www.ietf.org/rfc/rfc1945.txt344 Refer to http://www.ietf.org/rfc/rfc2965.txt

SAGA 4.0 127

Mandatory: Online Service Computer Interface (OSCI) Transport v1.2

The Online Service Computer Interface (OSCI)345 is the result of the MEDIA@Komm competition. OSCI covers a host of protocols which are suitable for eGovernment requirements and which are implemented by the OSCI steering group. The aim is to support transactions in the form of web services and their complete handling via the Internet.

OSCI Transport 1.2 is that part of "OSCI" which is responsible for the cross-section tasks in the security area. The existence of a central intermediary which can perform added-value services without jeopardizing confidentiality at the business case data level is a characteristic feature of the secure implementation of eGovernment processes using OSCI. As a secure transmission protocol, it enables binding online transactions (even in conformance to the German Act on Digital Signature).

OSCI Transport supports asynchronous communication via an intermediary as well as end-to-end encryption for the confidential transmission of data. OSCI Transport standardizes both message contents as well as transport and security functions and is based on international standards (including, for instance, XML Signature, DES, AES, RSA and X.509) for which suitable, concrete contents are developed as required.

Central design criteria for OSCI Transport, version 1.2, were the following.

a. Reference to open standards (SOAP, XML Signature, XML Encryption)

b. Technical independence, i.e. transmission using any technical communication protocol without any specific requirements regarding platforms or programming languages

c. Scalability of security levels (advanced signatures or qualified and/or accredited electronic signatures as required by the specific application).

Mandatory: Transport Layer Security (TLS) v1.0

TLS346 is a cryptographic protocol that ensures the integrity and confidentiality of a communication connection on the World Wide Web. It was developed from the Secure Sockets Layer (SSL) protocol. The SSL v3 standard, which was still mandatory in SAGA version 2.1, is listed in the Right of Continuance List. For security reasons, older SSL standards should no longer be used for existing applications.

TLS is based on TCP/IP and secure communication protocols for applications, such as HTTP, IIOP, RMI, etc., in a transparent manner. TLS-secured web pages are addressed with https:// rather than http://.

TLS also supports the single-ended authentication of the public agency's server in relation to the client of the communication partner in order to confirm to the latter that it is really connected to the public agency's server. Double-ended authentication of client and server can also be supported by TLS.

TLS offers the following cryptographic mechanisms.

345 Refer to http://www.osci.de/346 Published as RFC 2246, refer to http://www.ietf.org/rfc/rfc2246.txt

128 SAGA 4.0

a. Asymmetric authentication of the communication partners (via X.509 certificates)

b. Secure exchange of session keys (via RSA encryption or Diffie-Hellman key agreement)

c. Symmetric encryption of communication contents

d. Symmetric message authentication (via MACs) and protection against reply attacks

The principles of operation of TLS are described in detail in section 5.2.2 of the Guideline for the Introduction of the Electronic Signature and Encryption in the Administration issued by the Co-operation Committee for Automatic Data Processing for the Federal-government, Federal-state Government and Municipal Administration Sector (KoopA ADV)347. In TLS, the combination of different methods is referred to as a "cipher suite". A TLS cipher suite always contains four cryptographic algorithms: a signature method, a key exchange method, a symmetric encryption method as well as a hash function.

Recommended: Secure Shell v2 (SSH-2)

The SSH-2348 protocol is an enhanced version of the SSH which has existed since 1995. Using a standardized authentication procedure, it enables the opening of an encrypted tunnel between the client and server system and then permits encrypted user data to be sent and received via the transport layer. The different open-source and commercial implementations of this protocol enable strong encryption of user data and allow, for instance, remote control of remote computers and file transfer (SSH-FTP). This means that there is a secure alternative to FTP.

Recommended: WWW Distributed Authoring and Versioning (WebDAV)

WebDAV349 is a standard drafted by the Internet Engineering Task Force (IETF) which can be used as an extension of HTTP for writing and changing files in networks. It is hence an alternative to FTP. In contrast to FTP, when data is transmitted with WebDAV, no additional port has to be released because WebDAV uses the HTTP port 80. Write access based on passwords should be encrypted, e.g. via HTTPS or TLS. However, not all applications that support WebDAV also support so-called encryption mechanisms.

Under observation: Transport Layer Security (TLS) v1.1

Adopted in April 2006, TLS v1.1350 is a further development of TLS v1.0 that features improved security. Support of TLS v1.1 is planned for the next generation of web browsers.

8.7.6 Geo-servicesAll standards in this section are either specifications of the Open Geospatial Consortium (OGC)351 or are based on these specifications. The classifications were agreed to with Geo­

347 Refer to http://www.koopa.de/projekte/pki.html348 Published under RFC 4251 - 4256, refer to http://www.ietf.org/rfc.html349 Published as RFC 2518, refer to http://www.ietf.org/rfc/rfc2518.txt and

http://www.webdav.org/350 Published as RFC 4346, refer to http://www.ietf.org/rfc/rfc4346.txt351 Refer to http://www.opengeospatial.org/

SAGA 4.0 129

dateninfrastruktur Deutschland [Geo-data infrastructure Germany] (GDI-DE)352 and are orientated towards [GDI-DE 2007]. The definition of formats for exchanging geo-information can be found in section 8.6.11 on page 118.

Recommended: Catalogue Services Specification v2.0 – ISO Metadata Application Profile v1.0

The Catalogue Services Specification v2.0 – ISO Metadata Application Profile353 is an application profile for catalogue services which was adopted by the OGC. The profile refers to the CSW base specification of OGC and the metadata specifications of ISO (ISO 19115, ISO 19119). It should be used to implement standard-compliant metadata searches.

Recommended: Web Map Service Deutschland (WMS-DE) v1.0

The aim of the WMS-DE354 profile is to define in a binding manner the requirements of Geodateninfrastruktur Deutschland (GDI-DE) for a Web Map Service (WMS). With WMS services which use this profile, the user can achieve a nation-wide presentation by combining the digital maps and data of various WMS services. The binding parameters within the scope of GDI-DE should benefit both suppliers during the establishment of services as well as users during queries.

Recommended: Web Coverage Service (WCS) v1.0.0

WCS355 enables access to multi-dimensional grid data. This service is particularly suitable for submitting grid data, e.g. in shop solutions, for providing measured values in the form of time series, and for supplying digital terrain models.

Recommended: Web Feature Service (WFS) v1.0

WFS v1.0.0356 enables access to geo-data objects (features), usually in the form of vector data. Data is exchanged in the Geography Markup Language (GML) v2.1.2, refer to section 8.6.11 "Interchange formats for geo-information" on page 118.

Recommended: Web Feature Service (WFS) v1.1

Compared to its predecessor version 1.0.0, WFS v1.1.0357 is not yet so widely used. Data is exchanged in the Geography Markup Language (GML) v3.1.1, refer to section 8.6.11 "Interchange formats for geo-information" on page 118.

352 Refer to http://www.gdi-de.org/353 Refer to http://www.opengeospatial.org/standards/cat354 Refer to http://www.gdi-de.org/de/download/WMS_DE_Profil_V1.pdf355 Refer to http://www.opengeospatial.org/specs/356 Refer to http://www.opengeospatial.org/specs/357 Refer to http://www.opengeospatial.org/specs/

130 SAGA 4.0

Recommended: Simple Feature Access – Part 2: SQL option (SFA-2) v1.1.0

SFA-2358 defines interfaces for accessing geo-data objects (features). Along with OGC, this standard was standardized by ISO and is hence also called ISO 19125-2359.

8.8 BackendThe German administration uses several legacy systems which are very likely to remain in use even in the future (e.g. ERP, mainframe transaction processing, database systems and other legacy applications). Depending on the operating modes supported, these legacy systems can be divided into three categories as follows:

a. Transaction-secured processing by end users via existing dialogue systems,

b. asynchronous data batch processing (bulk data processing) and

c. program-to-program communication on the basis of proprietary protocols.

Two options are generally available for integrating legacy systems:

a. Direct integration via so-called "legacy interfaces" or

b. integration via a separate integration tier, with modular encapsulation of real access to the legacy systems.

Detailed solution concepts must be evaluated and compared with a view to the aims to be achieved, the time and budget available, as well as the functions to be supported during the integration of the legacy system.

The following sections discuss different solution concepts which have proven to be suitable with the three above-mentioned operating modes.

The data elements to be transmitted should be specified using the technologies described in section 8.3 "Data models" on page 96 AND section 8.6.6 "Interchange formats for data " on page 109.

8.8.1 Directory services and registries

Mandatory: Lightweight Directory Access Protocol (LDAP) v3

LDAP v3 (RFC 4510 - 4519360) is an X.500-based Internet protocol which is optimized with regard to hierarchically structured information and which is used for directory service access.

Under observation: Universal Description, Discovery and Integration (UDDI) v2.0

Analogous to section 8.7.1.2 "Middleware communication with applications outside theadministration" on page 123.

358 Refer to http://www.opengeospatial.org/specs/359 Refer to http://www.iso.org/360 Refer to http://www.ietf.org/rfc/rfc4510.txt

SAGA 4.0 131

Under observation: Directory Services Markup Language (DSML) v2

DSML361 is an XML-based language which is used to exchange data with directory services – e.g. during the course of queries and updates. Use of the specification makes it easy to access the directory services. DSML v2 was published in 2001 as an OASIS standard.

Under observation: ebXML Registry Services and Protocols (ebXML RS) v3.0/ ebXML Registry Information Model (ebXML RIM) v3.0

ebXML RS describes the services and protocols offered by an ebXML-compliant registry. An ebXML registry is a system that safely administers any particular content and the related, standardized metadata. ebXML RIM describes the pertinent information model. The technologies should be used together.

ebXML RS v3.0362 and ebXML RIM v3.0363 were adopted by OASIS364 on 1 May 2005 as OASIS standards. Compared to version 2.0, version 3.0 adds many useful features, such as versioning repository contents.

8.8.2 Access to databases

Mandatory: Java Database Connectivity (JDBC) v3.0

JDBC365 should be used for access to databases.

8.8.3 Access to legacy systems

Mandatory: Remote Method Invocation (RMI)

Analogous to section 8.7.1.1 "Middleware communication within the administration" on page 121.

Mandatory: Simple Object Access Protocol (SOAP) v1.1

Analogous to section 8.7.1.1 "Middleware communication within the administration" on page 121.

Mandatory: Web Services Description Language (WSDL) v1.1

Analogous to section 8.7.1.1 "Middleware communication within the administration" on page 121.

361 Refer to http://www.oasis-open.org/specs/index.php#dsmlv2362 Refer to http://www.oasis-open.org/specs/index.php#ebxmlrsv3.0363 Refer to http://www.oasis-open.org/specs/index.php#ebxmlrimv3.0364 Refer to http://www.oasis-open.org/365 Published as JSR-000054, refer to http://www.jcp.org/en/jsr/detail?id=54

132 SAGA 4.0

Mandatory: Java Message Service (JMS) v1.1

Analogous to section 8.7.1.1 "Middleware communication within the administration" on page 121.

Mandatory: J2EE Connector Architecture (JCA) v1.5

Analogous to section 8.7.1.1 "Middleware communication within the administration" on page 121.

Recommended: Java Language Mapping to OMG IDL

Analogous to section 8.7.1.1 "Middleware communication within the administration" on page 121.

Recommended: Web Services (WS) Security v1.1

Analogous to section 8.7.1.1 "Middleware communication within the administration" on page 121.

8.9 EncryptionCryptographic algorithms for encryption can be applied to data and/or keys in order to ensure their confidential transmission.

8.9.1 Asymmetric encryption methodsAsymmetric encryption methods are required, for example, in order to exchange a so-called session key between communication partners. A session key is a symmetric key, refer to section 8.9.2 on page 132.

Mandatory: RSA

The RSA method366 is the most important asymmetric method; it is also referred to as the public key method. During encryption, the bit sequence is encrypted using the public key of the communication partner. After this, the resultant encrypted secret text can only be decrypted to plain text by the holder of the private key. The security of this method is based on the difficulty to factorize large natural numbers. Normal key lengths are 2048 and 4096 bits. The Federal Network Agency no longer recommends 1024-bit keys.

RSA is used during encryption just like signing, refer to section 8.10.2 on page 134.

8.9.2 Symmetric encryption methodsSymmetric methods, when applied, use the same private key for encryption and decryption. These methods usually feature very high performance.

366 RSA was named after its inventors: Ronald L. Rivest, Adi Shamir and Leonard Adleman

SAGA 4.0 133

Mandatory: Advanced Encryption Standard (AES)

AES367 is a symmetric block cipher with a fixed block length of 128 bits and a key length that can be either 128, 192 or 256 bits long. AES was published in October 2000 by the National Institute of Standards and Technology (NIST)368.

The Triple Data Encryption Standard (Triple-DES, also called 3DES), which was still recommended in SAGA version 2.1, is now on the Right of Continuance List.

8.10 Electronic signatureThe security of an electronic signature is primarily dependent upon the strength of the underlying cryptographic algorithms. With regard to the "electronic signature" issue, refer also to section 4.5.1 on page 45.

Mandatory: Cryptographic algorithms for the electronic signature according to the Federal Network Agency

Every year, the Federal Network Agency publishes in the Federal Gazette those cryptographic algorithms which can be considered to be suitable for at least the next six years with a view to the requirements of the Act on Digital Signature (SigG) and the Digital Signature Ordinance (SigV)369. To this effect, the minimum dimensions of parameters, such as block sizes and key lengths, are stated which are needed to ensure sufficient security. The German Federal Office for Information Security (BSI) can classify further methods as suitable.

An electronic signature for the purposes of the Act includes the following cryptographic algorithms.

8.10.1 Hashing dataA hash function reduces the data to be signed to a hash value, i.e. a bit sequence with a fixed length. This then means that the hash value rather than the data itself is signed.

Mandatory: Secure Hash Algorithm (SHA)-256

SHA-256 (Secure Hash Algorithm)370, as a further development of SHA-1 (160-bit long hash value), is a cryptographic hash function that generates a 256-bit long hash value.

367 Refer to http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf, published as FIPS 197368 Refer to http://csrc.nist.gov/369 Refer to

http://www.bundesnetzagentur.de/enid/Veroeffentlichungen/Algorithmen_sw.html370 Published as FIPS PUBS 180-2, refer to http://csrc.nist.gov/publications/fips/fips180-2/fips180-

2.pdf

134 SAGA 4.0

Recommended: Secure Hash Algorithm (SHA)-224 / Secure Hash Algorithm (SHA)-384 / Secure Hash Algorithm (SHA)-512

SHA-224, SHA-384 und SHA-512 (Secure Hash Algorithm)371 are further developments of SHA-1 (160-bit long hash value) and constitute cryptographic hash functions that generate longer hash values (the length corresponds to the number stated).

8.10.2 Asymmetric signature methodsAn asymmetric signature method consists of a signing and a verification algorithm. The signature method is dependent on a key pair which consists of a private (i.e. secret) key for signing (generating) and the pertinent public key for verifying (checking) the signature.

Mandatory: RSA

Analogous to section 8.9.1 "Asymmetric encryption methods" on page 132, RSA should be used for the asymmetric signature method.

Recommended: Digital Signature Algorithm (DSA)

The Digital Signature Algorithm (DSA)372 is the signature method that was specified in the US Digital Signature Standard (DSS) in 1991. DSA is a pure signature algorithm. Although the US government has obtained a patent for DSS, its use is free. DSA is less widespread than RSA. The Federal Network Agency's algorithm catalogue foresees qualified electronic signatures starting in 2008 as opposed to the standard with bigger parameter lengths. Normal key lengths are 2048 and 4096 bits. The Federal Network Agency no longer recommends 1024-bit keys.

8.10.3 Key managementAs a precondition for applications to use electronic signatures, it must be possible to assign public electronic keys (public keys) to real individuals or institutions. In order to achieve interoperability between different applications, identical data formats must be in place, and standardized mechanisms must be used to read and write data.

Recommended: XML Key Management Specification (XKMS) v2

XKMS373 specifies protocols for the registration and distribution of public keys. The protocols were designed for interaction with XML Signature and XML Encryption and are hence used for XML-based communications, e.g. web services. The specification consists of two parts, i.e. the XML Key Registration Service Specification (X-KRSS) and the XML Key Information Service Specification (X-KISS).

371 Published as FIPS PUBS 180-2, refer to http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

372 Published as FIPS 186-2, refer to http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf

373 Refer to http://www.w3.org/TR/xkms2/

SAGA 4.0 135

Clients can use relatively simple XKMS queries to find and validate public keys, with relay servers accessing existing LDAP and OCSP infrastructures in order to answer these queries. This means that parallel use of different directory services is possible with just one protocol.

8.11 SmartcardsSmartcards are chip cards with an integrated processor; they are also referred to as microprocessor cards. In contrast to chip cards which are used to only save data (memory cards), smartcards can also process data. Smartcards can serve as a Personal Security Environment (PSE), in order to safely store trustworthy certificates and keys, and also as a (secure) signature generation unit.374

A distinction is made between contact smartcards and contactless smartcards. Whilst contact smartcards feature a visible, exterior contact surface, contactless smartcards establish contact with the reader devices by wireless communication (Radio Frequency IDentification – RFID).

8.11.1 Contact smartcards

Mandatory: Identification Cards - Integrated circuit cards

Contact smartcards should conform to the ISO/IEC 7816375 standard. The standard describes, for instance, dimensions, positioning contacts and labelling, electrical properties as well as transmission protocols.

8.11.2 Contactless smartcards

Mandatory: Identification Cards - Contactless integrated circuit cards

Contactless smartcards with a transmission rate of up to approx. 847 kbps – corresponding to a range of up to 0.1m – should conform to the ISO/IEC 14443376 standard. The standard describes in four parts the design, function and operation of these smartcards. The electronic passport377 is based on this standard. The electronic ID card, which is currently in the planning phase, is also to be based on this standard.

374 Refer to the German Federal Office for Information Security (BSI): "Grundlagen der elektronischen Signatur – Recht, Technik, Anwendung" [Fundamentals of the electronic signature - law, technology, application], 2006, http://www.bsi.de/esig/esig.pdf

375 Refer to http://www.iso.org/376 Refer to http://www.iso.org/377 Refer to http://www.epass.de/

136 SAGA 4.0

8.11.3 Reader units and interfaces for smartcards

Mandatory: Technical guideline for federal-government eCard projects (BSI TR-03116) v1.0

Smartcard applications which use cryptographic methods should consider the security requirements for the use of cryptographic methods in federal-government eCard projects described in technical guideline BSI TR-03116378 from the Federal Office for Information Security (BSI) .

Mandatory: Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 7

Components which support the universal "Cryptographic Token Interface" (Cryptoki) should conform to ISIS-MTT379 v1.1, Part 7 (Cryptographic Token Interface).

Under observation: Interoperability Specification for ICCs and Personal Computer Sys­tems (PC/SC) v2.0

PC/SC380 specifies an interface between card reader units and the applications.

Under observation: OpenCard Framework (OCF) v1.2

OCF381 specifies an interface between card reader units and the applications.

Under observation: Secure Interoperable ChipCard Terminal (SICCT) v1.10

SICCT382 describes a basic concept for application-independent terminals for smartcards based on ISO/IEC 7816 and ISO/IEC 14443383. Applications with high or very high security requirements can attempt to conform to SICCT.

8.12 Long-term archivingWith electronic documents becoming increasingly widespread in administrations, sustainable and long-term storage calls for standards for storage which warrant the authenticity and completeness of the documents.

378 Refer to http://www.bsi.bund.de/literat/tr/tr03116/BSI-TR-03116.pdf379 Refer to http://www.isis-mtt.org/380 Refer to http://www.pcscworkgroup.com/specifications/specdownload.php381 Refer to http://www.opencard.org/index-downloads.shtml382 Refer to

http://www.teletrust.de/fileadmin/files/publikationen/Spezifikationen/SICCT_Spezifikation_1.10.pdf

383 Refer to http://www.iso.org/

SAGA 4.0 137

Recommended: Tagged Image File Format (TIFF) v6.0

TIFF v6.0 should be used for the long-term archiving of graphics and b/w images. Maximum interoperability is particularly important in this area of application. This is why only properties from "Baseline TIFF" are to be used here, refer also to section 8.6.8 on page 115.

Recommended: Joint Photographic Experts Group (JPEG)

In analogy to section 8.6.8 "Interchange formats for graphics" on page 115, JPEG should be used for long-term archiving of images, in particular, for photos.

Recommended: Extensible Markup Language (XML) v1.0

XML is suitable for long-term archiving, however, the related schemas and XSL files must also be archived, refer to section 8.6.6 "Interchange formats for data " on page 109. Examples of XML-based languages for long-term archiving include Encoded Archival Description (EAD)384, Encoded Archival Context (EAC)385 and the Metadata Encoding and Transmission Standard (METS)386.

Recommended: ArchiSig, Grundsätze für die beweiskräftige und sichere Langzeitarchivierung digital signierter Dokumente [principles for conclusive and secure long-term archiving of electronically signed documents]

The ArchiSig387 project was carried out by various participants from the worlds of science and industry as well as with users under the leadership of Informatikzentrum Niedersachsen [Lower Saxon Computer Science Centre] and Staatliche Archivverwaltung Niedersachsen [Lower Saxon state archive administration]. It defines principles388 that should be observed for the long-term archiving of electronically signed documents.389

Recommended: Portable Document Format Archive - 1 (PDF/A-1)

The PDF/A-1390 standard (ISO 19005-1:2005391) is based on PDF v1.4, refer to section 8.6.7.1, with the restrictions that scripts are embedded and metadata is captured and no passwords, executable code or audio or video data are used.

Conformance to ISO 19005-1:2005 can be described on two different levels:

1. PDF/A-1b (also referred to as Level B Conformance) represents minimum conformance to the requirement that the generated appearance of the PDF file must be reproducible on a long-term basis.

384 Refer to http://www.loc.gov/ead/385 Refer to http://jefferson.village.virginia.edu/eac/386 Refer to http://www.loc.gov/standards/mets/387 Refer to http://www.archisig.de/388 Refer to http://www.archisig.de/grundsaetze.pdf389 ArchiSig is used, for instance, within the scope of the "ArchiSafe" project, refer to

http://www.archisafe.de/390 Refer to http://www.adobe.de/products/acrobat/pdfs/pdfarchiving.pdf391 Refer to http://www.iso.org/

138 SAGA 4.0

2. PDF/A-1a (also referred to as Level A Conformance) is based on Level B and additionally requires that the PDF file can be searched (text extraction). PDF/A-1a fully complies with the requirements of the ISO standard (full conformance).

The standard should be used for the long-term archiving of text and presentations. This standard recognized by ISO can be used to save the document contents, the document form and the metadata of the document in one archived file. The file can also be displayed without the original application. A barrier-free presentation of contents is also provided.

Under observation: Extensible Markup Language (XML) v1.1

Analogous to section 8.6.6 "Interchange formats for data " on page 109.

SAGA 4.0 139

Appendix A References

[APEC]

National Office for the Information Economy / CSIRO: APEC e-Business: What do Users need?, 2002http://nla.gov.au/nla.arc-25067http://www1.cmis.csiro.au/Reports/APEC_E-commerce.pdf

[BOL]

Federal Ministry of the Interior (editor): BundOnline 2005: Umsetzungsplan 2004 – Status und Ausblick, Dresden 2004http://www.kbst.bund.de/ (in the area of > eGovernment > Initiatives > BundOnline 2005 > Implementation plan and final report > 2004 – implementation plan)

[BSI 2005]

German Federal Office for Information Security: ITIL und Informationssicherheit – Möglichkeiten und Chancen des Zusammenwirkens von IT-Sicherheit und IT-Service-Management, Berlin, 2005http://www.bsi.de/literat/studien/ITinf/itil.pdf

[e-GIF]

Office of the e-Envoy: e- Government Interoperability Framework Version 6.0, 2004http://www.govtalk.gov.uk/schemasstandards/egif.asp http://www.govtalk.gov.uk/documents/e-gif-v6-0(1).pdfOffice of the e_Envoy: Technical Standards Catalogue Version 6.1, 2004http://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, 2005http://www.itl.nist.gov/fipspubs/

[GDI-DE 2007]

Geo-data infrastructure Germany: Architektur der Geodateninfrastruktur Deutschland, concept for the universal provision of geodata within the scope of eGovernment in Germany, version 1.0, 2007http://www.gdi-de.org/de/download/GDI_ArchitekturKonzept_V1.pdf

[IDABC]

European Commission: Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens, 2005http://europa.eu.int/idabc/

140 SAGA 4.0

[IEEE 2000]

Institute of Electrical and Electronics Engineers (IEEE): IEEE-Standard 1471-2000: Recommended Practice for Architectural Description of Software-Intensive Systems, 2000

[ISO 1996]

ISO/IEC 10746-3: Information technology – Open Distributed Processing – Reference Model: Architecture, Geneva 1996

[ITG 2000]

Informationstechnische Gesellschaft (ITG) im VDE: Electronic Government als Schlüssel der Modernisierung von Staat und Verwaltung. A memorandum by the specialist committee for administrative IT of Gesellschaft für Informatik e.V. (GI) and special unit 1 of Informationstechnische Gesellschaft (ITG) at the Association for Electrical, Electronic and Information Technologies (VDE), Bonn / Frankfurt 2000http://mediakomm.difu.de/documents/memorandum.pdf

[KBSt 2007]

KBSt: IT-Architekturkonzept für die Bundesverwaltung, 2007http://www.kbst.bund.de/architekturkonzept

[Kudraß 1999]

Kudraß, Thomas: Describing Architectures Using RM-ODP, online publication, 1999http://www.imn.htwk-leipzig.de/~kudrass/Publikationen/OOPSLA99.pdf

[Lenk et al. 2000]

Lenk, Klaus / Klee-Kruse, Gudrun: Multifunktionale Serviceläden, Berlin 2000

[Lenk 2001]

Lenk, Klaus: Über Electronic Government hinaus Verwaltungspolitik mit neuen Konturen, paper at the 4th conference on administrative IT at the Federal University of Applied Administrative Sciences on 5 September 2001

[v. Lucke et al. 2000]

Lucke, Jörn von / Reinermann, Heinrich: Speyerer Definition von Electronic Government. Results of the research project "government and administration in the information age", online publication, 2000http://foev.dhv-speyer.de/ruvii/Sp-EGov.pdf

[New Zealand]

State Services Commission, New Zealand: E- government in New Zealand, 2007http://www.e - government.govt.nz/

[Schedler et al. 2001]

Schedler, Kuno / Proeller, Isabella: NPM, Berne / Stuttgart / Vienna 2001

SAGA 4.0 141

[Schreiber 2000]

Schreiber, Lutz: Verwaltung going digit@l. Ausgewählte Rechtsfragen der Online-Verwaltung, in: Digitale Signaturen, in: Kommunikation & Recht, supplement 2 in edition 10/2000

[Switzerland]

Swiss Federal Chancellery: Sektion elektronischer Behördenverkehr, homepage of Beratungs-, Dienstleistungs- und Betriebsorganisation für den elektronischen Behördenverkehr [the advisory, service and provider organization for electronic communications with public agencies] (E-Government), 2007http://www.bk.admin.ch/org/bk/00346/00348/index.html?lang=de

[SIGA]

eGovernment project group at the German Federal Office for Information Security (BSI): Sichere Integration von E- Government-Anwendungen, module of the eGovernment manual, 2003http://www.bsi.bund.de/fachthem/egov/4_siga.htm

SAGA 4.0 143

Appendix B Overview of Classified Standards

.NET-Framework...............................................................................................................................100

A

Advanced Encryption Standard (AES)...........................................................................................133

AES......................................................................................................................................................133

Animated GIF.....................................................................................................................................116

Animated Graphics Interchange Format (Animated GIF) v89a................................................116

ANSI/NISO Z39.85...............................................................................................................................97

ArchiSig, Grundsätze für die beweiskräftige und sichere Langzeitarchivierung digitalsignierter Dokumente [principles for conclusive and secure long-term archiving ofelectronically signed documents]..................................................................................................137

B

Barrierefreie Informationstechnik Verordnung (BITV) [Barrier-free information technologyordinance].........................................................................................................................................105

BITV....................................................................................................................................................105

BPEL4WS............................................................................................................................................100

BSI, E-Government-Handbuch [eGovernment manual]......................................................95, 104

BSI, IT-Grundschutz-Kataloge [IT Baseline Protection Catalogues]...........................................94

BSI TR-03116.......................................................................................................................................136

BSI standard 100-1: Management systems for Information Security..........................................91

BSI standard 100-2: IT baseline protection approach...................................................................92

BSI-Standard 100-3: Risk analysis on the basis of IT baseline protection...................................93

Business Process Execution Language for Web Services (BPEL4WS) v1.1...............................100

C

C# Language Specification..............................................................................................................99

Cascading Style Sheets Language Level 2 (CSS2)..........................................................................107

Catalogue Services Specification v2.0 – ISO Metadata Application Profile v1.0....................129

CLI.........................................................................................................................................................99

Comma Separated Value (CSV).......................................................................................................112

Common Language Infrastructure (CLI)........................................................................................99

Cryptographic algorithms for the electronic signature according to the Federal NetworkAgency................................................................................................................................................133

CSS2.....................................................................................................................................................107

144 SAGA 4.0

CSV.......................................................................................................................................................112

D

DC.........................................................................................................................................................97

DCMI Metadata Terms.......................................................................................................................97

Digital Signature Algorithm (DSA).................................................................................................134

DIN 66001............................................................................................................................................95

Directory Services Markup Language (DSML) v2..........................................................................131

DNS......................................................................................................................................................124

Domain Name System (DNS)...........................................................................................................124

DSA......................................................................................................................................................134

DSML....................................................................................................................................................131

Dublin Core (DC).................................................................................................................................97

E

ebXML Registry Information Model (ebXML RIM) v3.0.............................................................131

ebXML Registry Services and Protocols (ebXML RS) v3.0.............................................................131

ebXML RIM.........................................................................................................................................131

ebXML RS............................................................................................................................................131

ECMA-262..........................................................................................................................................108

ECMA-334............................................................................................................................................99

ECMA-335..........................................................................................................................................100

ECMA-376..............................................................................................................................111, 112, 113

ECMAScript Language Specification.............................................................................................108

eGovernment manual.......................................................................................................................95

Election Markup Language (EML) v4.0.........................................................................................109

EML.....................................................................................................................................................109

Entity Relationship Diagram (ERD).................................................................................................96

ERD.......................................................................................................................................................96

Extensible Hypertext Markup Language (XHTML) Basic v1.0....................................................120

Extensible Hypertext Markup Language (XHTML) v1.0..............................................................107

Extensible Markup Language (XML) v1.0...............................................................................109, 137

Extensible Markup Language (XML) v1.1...............................................................................109, 138

Extensible Stylesheet Language (XSL) v1.0....................................................................................107

Extensible Stylesheet Language (XSL) v1.1....................................................................................108

Extensible Stylesheet Language Transformations (XSLT) v1.0...................................................107

Extensible Stylesheet Language Transformations (XSLT) v2.0...................................................108

SAGA 4.0 145

F

File Transfer Protocol (FTP)..............................................................................................................126

FIPS 186-2............................................................................................................................................134

FIPS 197...............................................................................................................................................133

FIPS PUBS 180-2..................................................................................................................................133

FTP.......................................................................................................................................................126

G

Geo Tagged Image File Format (GeoTIFF).....................................................................................116

Geography Markup Language (GML) v2.1.2..................................................................................119

Geography Markup Language (GML) v3.1.1...................................................................................119

GeoTIFF...............................................................................................................................................116

GIF v89a..............................................................................................................................................115

GML v2.1.2...........................................................................................................................................119

GML v3.1.1............................................................................................................................................119

Gnu ZIP (GZIP) v4.3............................................................................................................................119

Graphics Interchange Format (GIF) v89a......................................................................................115

H

H.323...................................................................................................................................................126

Handlungsleitfaden für die Einführung der elektronischen Signatur und Verschlüsselungin der Verwaltung v1.1 [Guideline for the Introduction of the Electronic Signature andEncryption in the Administration]..................................................................................................94

HTML............................................................................................................................................110, 113

HTML v4.01........................................................................................................................................106

HTTP v1.1......................................................................................................................................118, 126

Hypertext Markup Language (HTML) v4.01...................................................................106, 110, 113

Hypertext Transfer Protocol (HTTP) v1.1.................................................................................118, 126

I

Identification Cards - Contactless integrated circuit cards.......................................................135

Identification Cards - Integrated circuit cards.............................................................................135

IMAP v4rev1.......................................................................................................................................125

Industrial Signature Interoperability Specification – MailTrusT (ISIS-MTT) v1.1.....................93

Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 1 to Part6...........................................................................................................................................................125

Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 3........114

Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 7........136

Internet Message Access Protocol (IMAP) v4rev1........................................................................125

Internet Protocol (IP) v4...................................................................................................................124

146 SAGA 4.0

Internet Protocol (IP) v6...................................................................................................................124

Interoperability Specification for ICCs and Personal Computer Systems (PC/SC) v2.0..........136

IP v4.....................................................................................................................................................124

IP v6.....................................................................................................................................................124

ISIS-MTT v1.1........................................................................................................................................93

ISIS-MTT v1.1., Part 1 to Part 6...........................................................................................................125

ISIS-MTT v1.1., Part 3..........................................................................................................................114

ISIS-MTT379 v1.1, Part 7....................................................................................................................136

ISO 10646:2003..................................................................................................................................106

ISO 15836-2003....................................................................................................................................97

ISO 19005-1:2005...............................................................................................................................137

ISO 19125-2.........................................................................................................................................130

ISO/IEC 10746-3:1996..........................................................................................................................31

ISO/IEC 10918-1:1994...................................................................................................................115, 137

ISO/IEC 14443.....................................................................................................................................135

ISO/IEC-14496..............................................................................................................................116, 118

ISO/IEC 15444-1...................................................................................................................................116

ISO/IEC 15445.......................................................................................................................106, 110, 113

ISO/IEC 15948:2003...........................................................................................................................115

ISO/IEC 16262.....................................................................................................................................108

ISO/IEC 19503:2005......................................................................................................................96, 97

ISO/IEC 19757-2:2003..........................................................................................................................97

ISO/IEC 23270:2006............................................................................................................................99

ISO/IEC 23271:2006...........................................................................................................................100

ISO/IEC 26300:2006..............................................................................................................111, 112, 113

ISO/IEC 279001....................................................................................................................................83

ISO/IEC 7816.......................................................................................................................................135

ISO/IEC TR 23272:2006.....................................................................................................................100

ISO/PRF 19136......................................................................................................................................119

IT-Grundschutz-Vorgehensweise v1.0 [BSI standard 100-2: IT baseline protection approach]...............................................................................................................................................................92

IT-Grundschutzkataloge [IT Baseline Protection catalogues].....................................................83

ITU-T.81........................................................................................................................................115, 137

J

J2EE Connector Architecture (JCA) v1.5.................................................................................122, 132

Java Database Connectivity (JDBC) v3.0.........................................................................................131

Java EE v5.............................................................................................................................................98

Java Language Mapping to OMG IDL.....................................................................................122, 132

SAGA 4.0 147

Java Message Service (JMS) v1.1.................................................................................................121, 132

Java Network Launching Protocol (JNLP) v1.5..............................................................................102

Java Platform, Enterprise Edition (Java EE) v5...............................................................................98

Java Platform, Standard Edition (Java SE) v5..................................................................................99

Java SE..................................................................................................................................................99

Java Server Pages (JSP) v2.1...............................................................................................................107

Java Servlet v2.5.................................................................................................................................107

JCA...............................................................................................................................................122, 132

JDBC.....................................................................................................................................................131

JMS................................................................................................................................................121, 132

JNLP.....................................................................................................................................................102

Joint Photographic Experts Group (JPEG)...............................................................................115, 137

Joint Photographic Experts Group 2000 (JPEG2000) / Part 1.......................................................116

JPEG..............................................................................................................................................115, 137

JPEG2000............................................................................................................................................116

JSP v2.1.................................................................................................................................................107

JSR-000054.........................................................................................................................................131

JSR-000056 (Final Release)..............................................................................................................102

JSR-000112...................................................................................................................................122, 132

JSR-000154 (Maintenance Release)................................................................................................107

JSR-000176...........................................................................................................................................99

JSR-000244..........................................................................................................................................99

JSR-000245.........................................................................................................................................107

JSR-000914...................................................................................................................................121, 132

K

Kerberos v5........................................................................................................................................105

KoopA ADV, Handlungsleitfaden für die Einführung der elektronischen Signatur undVerschlüsselung in der Verwaltung v1.1 [Guideline for the Introduction of the ElectronicSignature and Encryption in the Administration]........................................................................94

L

LDAP v3...............................................................................................................................................130

Lightweight Directory Access Protocol (LDAP) v3.......................................................................130

M

Management systems for Information Security............................................................................91

Microsoft Windows .NET-Framework...........................................................................................100

MIME v1.0...................................................................................................................................106, 125

MP4...............................................................................................................................................116, 118

148 SAGA 4.0

MPEG-4 Part 14 (MP4).................................................................................................................116, 118

Multipurpose Internet Mail Extensions (MIME) v1.0...........................................................106, 125

O

OCF v1.2..............................................................................................................................................136

Office Open XML (OOXML)..................................................................................................111, 112, 113

Ogg...............................................................................................................................................117, 118

Ogg Encapsulation Format (Ogg)............................................................................................117, 118

Online Service Computer Interface (OSCI) Transport v1.2..........................................................127

OOXML...................................................................................................................................111, 112, 113

Open Document Format for Office Applications (OpenDocument) v1.0.....................111, 112, 113

OpenCard Framework (OCF) v1.2...................................................................................................136

OpenDocument v1.0............................................................................................................111, 112, 113

OSCI Transport 1.2.............................................................................................................................127

P

PC/SC...................................................................................................................................................136

PDF version 1.4......................................................................................................................110, 111, 112

PDF version 1.5......................................................................................................................110, 112, 113

PDF version 1.6......................................................................................................................110, 112, 113

PDF/A-1................................................................................................................................................137

PHP......................................................................................................................................................100

PHP Hypertext Preprocessor (PHP) v5.x........................................................................................100

PNG......................................................................................................................................................115

POP3....................................................................................................................................................125

Portable Document Format (PDF) v1.4..............................................................................110, 111, 112

Portable Document Format (PDF) v1.5.............................................................................110, 112, 113

Portable Document Format (PDF) v1.6.............................................................................110, 112, 113

Portable Document Format Archive - 1 (PDF/A-1).........................................................................137

Portable Network Graphics (PNG) v1.2...........................................................................................115

Post Office Protocol (POP) v3...........................................................................................................125

Q

Quicktime....................................................................................................................................116, 118

R

RDF.......................................................................................................................................................97

RealMedia v10.............................................................................................................................117, 118

Reference Model for Open Distributed Processing (RM-ODP69)................................................31

SAGA 4.0 149

Regular Language Description for XML New Generation (Relax NG)........................................97

Relax NG..............................................................................................................................................97

Remote Method Invocation (RMI)............................................................................................121, 131

Remote Method Invocation over Internet Inter ORB Protocol (RMI-IIOP) ..............................122

Resource Description Framework (RDF).........................................................................................97

RFC 1034/RFC 1035............................................................................................................................124

RFC 1510..............................................................................................................................................105

RFC 1700.............................................................................................................................................124

RFC 1939.............................................................................................................................................125

RFC 1945.............................................................................................................................................126

RFC 1952..............................................................................................................................................119

RFC 2045 to RFC 2049...............................................................................................................106, 125

RFC 2246.............................................................................................................................................127

RFC 2460............................................................................................................................................124

RFC 2518.............................................................................................................................................128

RFC 2616......................................................................................................................................118, 126

RFC 2821.............................................................................................................................................125

RFC 2965............................................................................................................................................126

RFC 3041.............................................................................................................................................124

RFC 3261.............................................................................................................................................126

RFC 3275..............................................................................................................................................114

RFC 3501.............................................................................................................................................125

RFC 3533.......................................................................................................................................117, 118

RFC 4251 - 4256..................................................................................................................................128

RFC 4346.............................................................................................................................................128

RFC 4510 - 4519..................................................................................................................................130

RFC 4810..............................................................................................................................................112

RFC 768...............................................................................................................................................124

RFC 791................................................................................................................................................124

RFC 793...............................................................................................................................................124

RFC 959..............................................................................................................................................126

Risikoanalyse auf der Basis von IT-Grundschutz v2.0 [BSI-Standard 100-3: Risk analysis onthe basis of IT baseline protection]..................................................................................................93

RM-ODP................................................................................................................................................31

RMI................................................................................................................................................121, 131

RMI-IIOP.....................................................................................................................................122, 132

Role models and flow charts............................................................................................................95

RSA...............................................................................................................................................132, 134

150 SAGA 4.0

S

SAML...................................................................................................................................................104

Secure Hash Algorithm (SHA)-224.................................................................................................134

Secure Hash Algorithm (SHA)-256.................................................................................................133

Secure Hash Algorithm (SHA)-384.................................................................................................134

Secure Hash Algorithm (SHA)-512..................................................................................................134

Secure Interoperable ChipCard Terminal (SICCT) v1.10..............................................................136

Secure Shell v2 (SSH-2)......................................................................................................................128

Security Assertion Markup Language (SAML) v2.0......................................................................104

Session Initiation Protocol (SIP) v2.0..............................................................................................126

SFA-2...................................................................................................................................................130

SHA-224..............................................................................................................................................134

SHA-256..............................................................................................................................................133

SHA-384..............................................................................................................................................134

SHA-512...............................................................................................................................................134

Short Message Services (SMS)..........................................................................................................120

SICCT..................................................................................................................................................136

Simple Feature Access – Part 2: SQL option (SFA-2) v1.1.0............................................................130

Simple Mail Transfer Protocol (SMTP)............................................................................................125

Simple Object Access Protocol (SOAP) v1.1.......................................................................121, 123, 131

SIP........................................................................................................................................................126

SMIL.....................................................................................................................................................113

SMS......................................................................................................................................................120

SMTP...................................................................................................................................................125

SOAP......................................................................................................................................121, 123, 131

SSH-2...................................................................................................................................................128

Synchronized Multimedia Integration Language (SMIL) v2.0...................................................113

T

Tagged Image File Format (TIFF) v6.0....................................................................................115, 137

Tape ARchive (TAR)...........................................................................................................................119

TAR.......................................................................................................................................................119

Technical guideline for federal-government eCard projects (BSI TR-03116) v1.0...................136

Text.......................................................................................................................................................111

TIFF...............................................................................................................................................115, 137

TLS v1.0................................................................................................................................................127

TLS v1.1................................................................................................................................................128

Transport Layer Security (TLS) v1.0.................................................................................................127

Transport Layer Security (TLS) v1.1..................................................................................................128

SAGA 4.0 151

U

UDDI....................................................................................................................................123, 124, 130

UML......................................................................................................................................................96

Unicode v4.x UTF-16.........................................................................................................................106

Unicode v4.x UTF-8...........................................................................................................................106

Unified Modeling Language (UML) v. 2.0.......................................................................................96

Universal Description, Discovery and Integration (UDDI) v2.0..................................123, 124, 130

UTF-16.................................................................................................................................................106

UTF-8..................................................................................................................................................106

W

WAP v2.0............................................................................................................................................120

WCS v1.0.............................................................................................................................................129

Web Coverage Service (WCS) v1.0.0...............................................................................................129

Web Feature Service (WFS) v1.0......................................................................................................129

Web Feature Service (WFS) v1.1.......................................................................................................129

Web Map Service Deutschland (WMS-DE) v1.0............................................................................129

Web Services (WS) Security v1.1.......................................................................................122, 123, 132

Web Services Business Process Execution Language (WS-BPEL) v2.0......................................100

Web Services Description Language (WSDL) v1.1...........................................................121, 123, 131

WebDAV.............................................................................................................................................128

WFS v1.0.0..........................................................................................................................................129

WFS v1.1.0...........................................................................................................................................129

Windows Media Video (WMV) v9............................................................................................117, 118

Wireless Application Protocol (WAP) v2.0....................................................................................120

WMS-DE.............................................................................................................................................129

WMV.............................................................................................................................................117, 118

WS-BPEL v2.0.....................................................................................................................................100

WS-Security........................................................................................................................122, 123, 132

WSDL.....................................................................................................................................121, 123, 131

WWW Distributed Authoring and Versioning (WebDAV)........................................................128

X

XAdES..................................................................................................................................................114

XForms v1.0........................................................................................................................................108

XHTML Basic v1.0..............................................................................................................................120

XHTML v1.0........................................................................................................................................107

XKMS...................................................................................................................................................134

XMI.................................................................................................................................................96, 97

152 SAGA 4.0

XML Advanced Electronic Signatures (XAdES) v1.2......................................................................114

XML Encryption.................................................................................................................................114

XML Key Management Specification (XKMS) v2..........................................................................134

XML Metadata Interchange (XMI) v2.x.....................................................................................96, 97

XML Schema Definition (XSD) v1.0...................................................................................................96

XML Signature...................................................................................................................................114

XML v1.0......................................................................................................................................109, 137

XML v1.1.......................................................................................................................................109, 138

XSD.......................................................................................................................................................96

XSL v1.0...............................................................................................................................................107

XSL v1.1................................................................................................................................................108

XSLT v1.0.............................................................................................................................................107

XSLT v2.0............................................................................................................................................108

Z

ZIP v2.0................................................................................................................................................119

SAGA 4.0 153

Appendix C Abbreviations

3DES Triple Data Encryption Standard

AES Advanced Encryption Standard

AG Public limited company in Germany

APEC Asia-Pacific Economic Cooperation

API Application Programming Interface

ArchiSig Conclusive and secure long-term archiving of electronically signed documents

BGG Law on equal opportunities for the disabled

BIT Federal Office for Information Technology

BITV Barrier-free information technology ordinance

BMI Federal Ministry of the Interior

BMP Windows Bitmap

BNetzA Federal Network Agency for electricity, gas, telecommunications, post and railways

BOL 2005 BundOnline Initiative

BPEL4WS Business Process Execution Language for Web Services

BSI German Federal Office for Information Security

CA Certification Authority

CC VBPO The "workflow management, processes and organization" competence centre

CEN Comité Européen de Normalisation

CMS Content Management System

CORBA Common Object Request Broker Architecture

CSIRO Commonwealth Scientific and Industrial Research Organisation

CSS Cascading Style Sheets Language

CSV Character Separated Value

CSW Web Catalogue Service

CTI Computer Telephony Integration

DCMI Dublin Core Metadata Initiative

DES Data Encryption Standard

DIN The German Institute for Standardization

154 SAGA 4.0

DNS Domain Name System

DOMEA Document management and electronic archiving in IT-based workflows

DRV German Federal Pension Insurance

DSA Digital Signature Algorithm

DSML Directory Services Markup Language

DSS Digital Signature Standard

DV Data processing

DVDV German Directory of Administrative Services

ebXML Electronic Business using XML

ECMA European Computer Manufacturers Association

OFA One-for-all

e-GIF E-Government Interoperability Framework

EJB Enterprise JavaBeans

EML Election Markup Language

ER Entity Relationship

ERP Enterprise Resource Planning

ETSI European Telecommunications Standards Institute

EU European Union

FinTS Financial Transaction Services

FIPS-PUBS Federal Information Processing Standards Publications

FLAC Free Lossless Audio Codec

FMS Formular Management System

FTP File Transfer Protocol

G2B Government to Business

G2C Government to Citizen

G2E Government to Employee

G2G Government to Government

GDI-DE Geo-data infrastructure Germany

GI Gesellschaft für Informatik e.V.

GIF Graphics Interchange Format

GML Geography Markup Language

GSM Global System for Mobile Communications

HTML Hypertext Markup Language

SAGA 4.0 155

HTTP Hypertext Transfer Protocol

HTTPS Secure Hypertext Transfer Protocol

IANA Internet Assigned Numbers Authority

IDABC Interoperable Delivery of European eGovernment Services to public Admin­istrations, Businesses and Citizens

IEC International Electrotechnical Commission

IETF Internet Engineering Task Force

IIOP Internet Inter-ORB Protocol

IMAP Internet Message Access Protocol

IP Internet Protocol

IPsec Internet Protocol Security

ISIS Industrial Signature Interoperability Specification

ISIS-MTT Industrial Signature Interoperability Specification - MailTrusT

ISMS Information Security Management System

ISO International Organization for Standardization

IT Information technology

ITG Informationstechnische Gesellschaft im VDE

ITIL IT Infrastructure Library

ITU International Telecommunication Union

ITU-T ITU Telecommunication Standardization Sector

IVBB Berlin-Bonn Information Network

IVBV Federal Administration Information Network

J2EE Java 2 Platform, Enterprise Edition

JAAS Java Authentication and Authorization Service

Java EE Java Platform, Enterprise Edition

Java SE Java Platform, Standard Edition

JAXP Java API for XML Parsing

JCA J2EE Connector Architecture

JDBC Java Database Connectivity

JMS Java Message Service

JMX Java Management Extensions

JNDI Java Naming and Directory Interface

JNLP Java Network Launching Protocol

156 SAGA 4.0

JPEG Joint Photographic Experts Group

JRE Java Runtime Environment

JSP Java Server Pages

JSR Java Specification Requests

JTA Java Transaction API

KBSt Co-ordinating and Advisory Agency of the Federal Government for Information Technology in the Federal Administration at the Federal Ministry of the Interior

KoopA ADV Co-operation Committee for Automatic Data Processing for the 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

MTT MailTrusT

NAT Network Address Translation

NISO National Information Standards Organization

NIST National Institute of Standards and Technology

OASIS Organization for the Advancement of Structured Information Standards

OCSP Online Certificate Status Protocol

ODF OpenDocument Format

OGC Open Geospatial Consortium

OMG Object Management Group

OOXML Office Open XML

OSCI Online Services Computer Interface

OSS Open Source Software

PC Personal Computer

PDA Personal Digital Assistant

PDF Portable Document Format

PDF/A PDF Archive

PHP PHP: Hypertext Preprocessor

SAGA 4.0 157

PIN Personal identification number

PKCS Public Key Cryptography Standards

PKI Public Key Infrastructure

PKIX IETF Working Group "Public-Key Infrastructure (X.509)"

PNG Portable Network Graphics

POP Post Office Protocol

PSE Personal Security Environment

RDF Resource Description Framework

Relax NG Regular Language Description for XML New Generation

REL Rights Expression Language

RFC Request for Comments

RFP Request for Proposals

RFID Radio Frequency Identification

RIPE RACE Integrity Primitives Evaluation

RIPEMD RIPE (RACE Integrity Primitives Evaluation) Message Digest

RMI Remote Method Invocation

RMI-IIOP Remote Method Invocation over Internet Inter-ORB Protocol

RM-ODP Reference Model of Open Distributed Processing

RSA Rivest, Shamir, Adleman Public Key Encryption

SAGA Standards and Architectures for eGovernment Applications

SAML Security Assertion Markup Language

SC Service Center

SFA Simple Feature Access

SGML Standard Generalized Markup Language

SHA Secure Hash Algorithm

SIGA Secure integration of eGovernment applications

SigG German Digital Signature Act

SigV Digital Signature Ordinance

SIP Session Initiation Protocol

SLA Service Level Agreement

SMIL Synchronized Multimedia Integration Language

S/MIME Secure Multipurpose Internet Mail Extensions

SMS Short Message Service

158 SAGA 4.0

SMTP Simple Mail Transfer Protocol

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

SQL Structured Query Language

SSH Secure Shell

SSL Secure Sockets Layer

TAN Transaction number

TAR Tape Archive

TCP/IP Transmission Control Protocol / Internet Protocol

TESTA Trans-European Services for Telematics between Administrations

TIFF Tagged Image File Format

TLS Transport Layer Security

TMS Travel Management System

Triple-DES Triple Data Encryption Standard

UDDI Universal Description, Discovery and Integration

UDP User Datagram Protocol

UML Unified Modeling Language

UN/CEFACT United Nations Centre for Trade Facilitation and Electronic Business

URL Uniform Resource Locator

UTF Unicode Transformation Format

VDE Association for Electrical, Electronic and Information Technologies

VLAN Virtual Local Area Network

VM Virtual Machine

VoIP Voice over IP (IP telephony)

V-PKI Administration Public Key Infrastructure (Administration PKI)

VPN Virtual Private Network

W3C World Wide Web Consortium

WAP Wireless Application Protocol

WCAG Web Content Accessibility Guidelines

WCS Web Coverage Service

WebDAV WWW Distributed Authoring and Versioning

WFS Web Feature Service

WML Wireless Markup Language

SAGA 4.0 159

WMS Web Map Service

WMV Windows Media Video

WS Web Service

WS-BPEL Web Services Business Process Execution Language

WSDL Web Services Description Language

WS-I Web Service Interoperability Organization

WS-Security Web Services Security

WWW World Wide Web

XadES XML Advanced Electronic Signatures

XHTML Extensible Hypertext Markup Language

X-KISS XML Key Information Service Specification

XKMS XML Key Management Specification

X-KRSS XML Key Registration Service Specification

XMI XML Metadata Interchange

XML Extensible Markup Language

XÖV XML-based technical standards for electronic data exchange within and with the public administration.

XSD Extensible Markup Language Schema Definition

XSL Extensible Stylesheet Language

XSLT Extensible Stylesheet Language Transformations