„SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии

  • 4,079 views
Uploaded on

„SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии …

„SAGA“ 4.0 - Стандарты и архитектуры для электронного правительства в Германии

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
4,079
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
23
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. SAGAStandards and Architectures for eGovernment ApplicationsVersion 4.0March 2008
  • 2. 2 SAGA 4.0Reprint, even in part, subject to approvalThis volume was prepared by the Federal Ministry of the Interiorin co-operation with ]init[ AG andFraunhofer-Institut für Software- und Systemtechnik (ISST).Homepage and download of the digital version: http://www.cio.bund.de/sagamail to: IT2@bmi.bund.de
  • 3. SAGA 4.0 3SAGAStandards and Architectures for eGovernment ApplicationsVersion 4.0March 2008Published bythe Federal Ministry of the Interior
  • 4. 4 SAGA 4.0
  • 5. SAGA 4.0 5Word of thanksThe Federal Ministry of the Interior and the SAGA authors would like to thank therepresentatives from the federal states and municipalities in the KoopA-SAGA projectgroup, the representatives from the central IT service providers of the federaladministration along with all the members of the SAGA expert group for their supportduring 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 forumand the SAGA contact form and whose committed comments constituted a valuablecontribution towards updating the document.
  • 6. 6 SAGA 4.0Introduction:This document presents in concise form widely used standards, processes, and methods ofstate-of-the-art IT development for eGovernment applications. Due to the nature of thissubject, 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 areproducts of certain manufacturers or standardization organizations that are protected atnational and international level.In the interest of a simple structure, copyright and source references of this kind weregenerally omitted. The use of a "name" or abbreviation in this document does notmean that they are free from copyrights or intellectual property rights of thirdparties.Furthermore, neither the editor, the authors nor the experts consulted can accept anyresponsibility for the technical functioning, compatibility or completeness of the standardsdiscussed. This version 4.0 was published in October 2007. Please send any comments,amendments or corrections to: Bundesministerium des Innern, Referat IT2. Thesecomments, amendments or corrections can also be published on the SAGA forum athttp://www.cio.bund.de.Version numbers are stated when they are relevant in the specific context discussed. If noversion numbers of standards are stated, the version which is most stable from a marketpoint 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 isquoted 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/sagawas moved to http://www.cio.bund.de/saga. Therefore some of the links given in thisdocument are no longer valid. For information on SAGA please refer tohttp://www.cio.bund.de/saga.
  • 7. SAGA 4.0 7Table of Contents 0 Status, revision history and outlook..................................................................................................9 0.1 Amendments to version 3.0................................................................................................................9 0.2 Future issues.........................................................................................................................................10 1 Introduction..........................................................................................................................................11 1.1 Background...........................................................................................................................................11 1.2 Readers of this document...................................................................................................................11 1.3 Aims........................................................................................................................................................12 1.4 Tasks.......................................................................................................................................................12 1.5 Basic principles for eGovernment applications.............................................................................13 1.6 Relationships with other eGovernment documents.....................................................................13 1.7 The evolution process.........................................................................................................................17 1.8 Structure of the document.................................................................................................................18 2 Fundamentals of SAGA.......................................................................................................................19 2.1 Scope of validity and binding effect of SAGA..................................................................................19 2.2 Minimum requirements with regard to the openness of standards.........................................20 2.3 Classification and life cycles of standards.......................................................................................20 2.4 SAGA conformance.............................................................................................................................25 3 Architecture model for eGovernment applications......................................................................31 3.1 Overview...............................................................................................................................................31 3.2 Enterprise viewpoint..........................................................................................................................32 3.3 Information viewpoint.......................................................................................................................33 3.4 Computational viewpoint.................................................................................................................34 3.5 Engineering viewpoint......................................................................................................................34 3.6 Technology viewpoint........................................................................................................................34 4 Enterprise viewpoint: Fundamentals of eGovernment...............................................................35 4.1 Definitions of eGovernment in Germany.......................................................................................35 4.2 The philosophy underlying eGovernment.....................................................................................36 4.3 Strategic goals......................................................................................................................................37 4.4 Organizational requirements...........................................................................................................41 4.5 Legal frame of reference....................................................................................................................45 4.6 Processes in eGovernment................................................................................................................49 4.7 Modules for the implementation of eGovernment applications...............................................52 5 Information viewpoint: Standardization of data models............................................................55 5.1 Levels of interoperability...................................................................................................................55 5.2 Purpose of standardizing data models...........................................................................................56 5.3 The Deutschland-Online "Standardisierung" [Standardization] project.................................57 5.4 Support for data model developers.................................................................................................59 6 Computational viewpoint: Reference software architecture....................................................65 6.1 General requirements for software applications..........................................................................65 6.2 Implementation options and architecture paradigms................................................................67
  • 8. 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 Presentation.......................................................................................................................................105 8.7 Communication.................................................................................................................................121 8.8 Backend...............................................................................................................................................130 8.9 Encryption..........................................................................................................................................132 8.10 Electronic signature..........................................................................................................................133 8.11 Smartcards..........................................................................................................................................135 8.12 Long-term archiving.........................................................................................................................136Appendix A References..........................................................................................................................................139Appendix B Overview of Classified Standards....................................................................................................143Appendix C Abbreviations.....................................................................................................................................153
  • 9. SAGA 4.0 90 Status, revision history and outlook0.1 Amendments to version 3.0This document is a revised version of SAGA, version 3.0. The following changes have beenmade:In chapter 2 "Fundamentals of SAGA", the names of the lists for the extended classificationof technical standards outside the document (White List, Grey List, Black List) were replacedwith 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 wasalso 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 governments signature projects and initiatives"7 .Chapter 5 "Information viewpoint: Standardization of data models" was revised with a viewto the Deutschland-Online "Standardization"8 project and the topics of XGenerator 2.09 andCore Components10.Chapter 6 "Computational viewpoint: Reference software architecture" now also includessections on architecture decisions11 and information addressing the introduction of serviceoriented 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) [GermanDirectory 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 combined1 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. 10 SAGA 4.0to form chapter 8 "Technology viewpoint: Standards for IT architecture and data security".Moreover, products and implementations were persistently replaced by the underlyingstandards. The previous positive list of supported plug-ins was replaced by a list ofrequirements which plug-ins should fulfil in the federal administrations eGovernmentapplications. The topics of "IP telephony"15 and "Registries"16 were re-introduced and thetopic of "Smartcards"17, which was already addressed in SAGA 3.0, was dealt with in moredetail.SAGA 4.0 no longer features a separate appendix for the one-for-all offers (OFA offers) by thefederal administration. The OFA offers will be soon described and will be updated outside ofSAGA 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 conceptwere 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 classificationof existing standards was changed and standards were moved from the document to theRight 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 ofSAGA:a. Development and standardization of process and data modelsb. IT service management on the basis of the "IT Infrastructure Library" (ITIL) v3.0c. Long-term archiving of dynamic information from databases and websitesd. Communication per instant messaging and chate. Exchange and visualization of 3D dataBesides the SAGA document, the Federal Ministry of the Interior also provides additionalinformation, 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/efa19 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
  • 11. SAGA 4.0 111 Introduction1.1 BackgroundIn an effort to create a more modern and service-orientated administration, the FederalGovernment is implementing more and more administration processes electronically. Theapplication of eGovernment is making it possible for citizens, business and administrationsto handle matters both faster and more efficiently. Standards are needed in order to enablethese many different applications for the future and accessible for all. This is guaranteed bythe Standards and Architectures for eGovernment Applications (SAGA) guideline.Shortly after the launch of the nation-wide BundOnline Initiative, the Co-ordinating andAdvisory Agency of the Federal Government for Information Technology in the FederalAdministration (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 offermore than 400 online services with Internet capability.On the basis of this success, the SAGA expert group continuously accompanies work on thestandards. In this version 4.0, central IT service providers from the federal administrationwere involved for the first time in updating the guideline. The latest developments andexperience are being added to the document through the discussion in the public SAGAforum. In close co-operation with a KoopA-SAGA project group22, the specific requirementsof the federal states and municipalities are also being included. With this knowledge, theSAGA authors regularly prepare an updated version with the Federal Ministry of the Interiorwhich is in charge of content.A host of completed projects has now been orientated towards the state-of-the-art andinvestment-safe standards and technologies recommended by SAGA. Many federalagencies use SAGA to plan and implement their IT projects, so that they can shape theinteroperability of the various planned and existing applications.Widespread acceptance and especially growing interest among federal states andmunicipalities are proof that SAGA is becoming increasingly important for eGovernment inGermany. In this version 4.0, SAGA once again offers a guideline for the economic andfuture-orientated implementation of IT projects in administrations.1.2 Readers of this documentSAGA is primarily designed for decision-makers in the fields of organization, informationtechnology and eGovernment teams in German administrations. The document is aguideline that serves as an orientation aid when it comes to developing concepts fortechnical 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. 12 SAGA 4.0Application developers should feel free to seek further detailed solutions whenever thestandards and solution proposals presented herein are not sufficient for theimplementation of technical requirements.The Federal Government also sees its initiative as a contribution towards the developmentof eGovernment in Germany. The experience gained within the scope of the initiativeshould 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 Governmentb. Reusability – re-use of process and data models, systems, services and components in various eGovernment projects in order to generate synergiesc. Openness – Inclusion of open standards in eGovernment applications in order to promote their long-term usability23d. Reduction of costs and risks – Considering investment-safe developments on the market and in the field of standardizatione. Scalability – Ensuring the usability of applications as requirements change in terms of volume and transaction frequency1.4 TasksSAGA pursues a comprehensive standardization approach for Germanys administrations inorder to achieve the following goals.Defining technical Standards and Architectures for eGovernment ApplicationsThe technical standards and architectures cover all the levels and elements relevant foreGovernment. They form the basis for the interoperability and compatibility of theeGovernment applications to be developed.Standardizing processes and data in administrationsIn order to achieve interoperability and compatibility of eGovernment applications, it isnecessary to create a basis for standardizing processes and data in Germanysadministrations. In an effort to support this, systems and services are described on the KBStwebsite 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 2024 OFA offering and networks: http://www.kbst.bund.de/efa
  • 13. SAGA 4.0 131.5 Basic principles for eGovernment applicationseGovernment applications are designed to fully reach their target groups. This is why itshould be possible to access all the functions irrespective of the users selected platform, theconfiguration of the user systems or the abilities of the users. eGovernment applicationsmust be orientated towards the requirements and needs of the target groups.On the basis of these preconditions, the following basic principles are laid down foreGovernment 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 browsers 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 documentsTrials with standards and architectures for eGovernment have been underway for someyears now in Germany and in other countries26. Experience from these trials andinternational 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 updatesare released. This means that SAGA supersedes contents and information of olderdocuments and that new documents consider the contents and information of the latestSAGA version. A broad-based co-ordination process accompanies any SAGA update in orderto avoid conflicts with valid documents.E-Government-Handbuch [eGovernment manual]In order to promote the Federal Governments eGovernment initiative – such as theBundOnline 2005 Initiative that was completed in 2005 – and to support federal-state andmunicipal agencies, the E-Government-Handbuch27 [eGovernment manual] is preparedunder the leadership of the German Federal Office for Information Security. This manual is25 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. 14 SAGA 4.0designed as a reference manual and central information exchange for issues related toeGovernment.The E-Government-Handbuch [eGovernment manual] is a modular compilation of materialthat covers a broader range of issues and topics than SAGA. As far as identical issues areaddressed, the E-Government-Handbuch [eGovernment manual] does so in a moreconcrete manner. This is why certain modules of the eGovernment manual are referencedfrom within SAGA28. SAGA sets forth guidelines, whilst the E-Government-Handbuch[eGovernment manual] explains the implementation of these guidelines and offerspractical advice.In mid-February 2003, SAGA became part of the E-Government-Handbuch [eGovernmentmanual]. It is the module of the manual with the strongest binding effect. All the othermodules are designed to ensure conformity with SAGA.When examining the focal issue of "IT and IT security", the study titled "Sichere Integrationvon E-Government-Anwendungen(SIGA)"29 [Secure integration of eGovernmentapplications] was drafted. The aim of this study is to adapt the technologies presented inSAGA 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 recommendsstandard security measures for typical IT systems in its IT-Grundschutz30 [IT baselineprotection]. 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 systemswhich is reasonable and sufficient for normal protection requirements and which can serveas a basis for IT systems and applications with high security requirements.IT-Grundschutz [IT baseline protection] includes the BSI-Standards31 [BSI standards] for ITsecurity management and the IT-Grundschutz-Kataloge32 [IT baseline protectioncatalogues] which replace the previous IT-Grundschutzhandbuch [IT Baseline ProtectionManual]. 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] and28 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 10429 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
  • 15. SAGA 4.0 15c. 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 [ITbaseline protection catalogues] are defined as mandatory standards36.Barrierefreie Informationstechnik-Verordnung – BITV [barrier-free information technologyordinance]The ordinance on the creation of barrier-free information technology pursuant to section 11of Behindertengleichstellungsgesetz [law on equal opportunities for the disabled](Barrierefreie Informationstechnik-Verordnung – BITV)37, which came into effect on 24 July2002, is referenced in SAGA and is defined as a mandatory standard with regard to theimplementation of the presentation and client layers38.V-Modell XTThe V-Modell XT39 is the binding process model throughout the federal administration forthe development of IT systems for the federal authorities. The V-Modell XT must beconsidered in strategic planning and project management efforts and in conjunction withthe implementation of eGovernment applications.Used as a guideline for planning and implementing development projects, this modeldefines 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 beachieved. Furthermore, the V-Modell XT also defines the responsibilities of each projectparticipant. It hence serves as a basis for contracts, as a guideline for work and as a basis forcommunication.The V-Modell XT is subject to ongoing upgrading in the form of releases.IT Infrastructure Library – ITILWhen 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 becomeestablished as the globally accepted defacto standard. This is why KBSt has issued a series ofpublications concerning the application of ITIL40.In ITIL, Service Management addresses a general-interest topic that must be consideredfrom the beginning of the lifecycle of an IT application. This results in synergies for theapproach 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. 16 SAGA 4.0During the preparation of SAGA 4.0, an upgraded ITIL, version 3.0, was issued. In order touse a tried-and-tested approach as a basis and to be able to refer to German literature, ITILversion 2.0, which is supported by KBSt documents, is presented in the EngineeringViewpoint (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 thisguide is the replacement of proprietary products both with open source software (OSS) and– where necessary – future generations of proprietary products. Agency-specific scenariosare developed and different migration alternatives are discussed.The Migrationsleitfaden [migration guide] was developed with a view to SAGA version 2.1 asfar as relevant interfaces were concerned. SAGA updates will have no repercussions on thestatements made.DOMEA-Konzept [DOMEA concept]DOMEA44 stands for "Dokumentenmanagement und elektronische Archivierung"[document management and electronic archiving] in IT-based workflows. The aim of thisconcept is to introduce the electronic file. Physical files are to be replaced with workflows atpublic agencies in the form of fully electronic, media-consistent procedures. The electronicfile is subject to the same legal and functional requirements as conventional files. Since thepublication of the concept in 1999, DOMEA has become an established standard forelectronic workflows at federal, federal-state and municipal agencies. For productmanufacturers, the DOMEA-Konzept [DOMEA concept] is a major source of informationwhen it comes to identifying the demands of public administrations which are consideredwhen products are developed further.Besides the organizational concept and the resultant requirements catalogue, the modularconcept includes further elements which address specific issues of the organizationalconcept in more detail.The requirements catalogue of the DOMEA concept translates organizational requirementsinto functional requirements which are orientated towards the SAGA standards on the onehand whilst also influencing the updating process of the SAGA document on the other. TheDOMEA concept describes the relevant requirements for software products related to thearea of electronic workflow management. These requirements are in some respects evenmore 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
  • 17. SAGA 4.0 171.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 authorsb. Examination of proposals by the SAGA authorsc. Discussion in the SAGA expert group on the standards and architectures which were found to be suitable by the SAGA authorsd. Acceptance of proposals in a KBSt resolution on the basis of the discussion between the SAGA authors and the SAGA expert groupe. Inclusion of the accepted standards and architectures in SAGA by the SAGA authors as soon as the resolution has been made by the KBStSAGA is updated at regular intervals, amended to reflect the latest developments andfindings 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 forumA public forum at: http://www.kbst.bund.de/saga-forum enables Internet users to registerand discuss issues related to the application and further development of SAGA. The resultsof the discussions are evaluated and, if suitable, are considered in the next version of theSAGA document.Contact formThe SAGA homepage provides a contact form47 for SAGA users. This form can be used tosend structured ideas and queries directly to the SAGA authors.The SAGA expert groupThe KBSt has established an expert group48 comprising representatives from business,science and administration and appoints the members. This expert group is involved in theupdating process at regular intervals or whenever there is reason for involvement.The KoopA-SAGA project group and central IT service providers of the federal administrationThe Co-operation Committee for Automatic Data Processing for the Federal-government,Federal-state Government and Municipal Administration Sector (KoopA ADV) delegates45 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. 18 SAGA 4.0representatives from the federal states and municipalities to accompany the furtherdevelopment of SAGA in workshops. The SAGA authors draft a catalogue of questions forproposed amendments which are answered by the participants and supplemented by theirown proposals. In analogy to this approach, the requirements of the central IT serviceproviders of the federal administration are collected in workshops and written exchangesand taken into consideration in the updating of the document.SAGA examination reportThe proposals put to the SAGA authors in the public forum, via the contact form, in theSAGA expert group, in the KoopA-SAGA project group and by the central IT serviceproviders of the federal administration are listed in a SAGA examination report49 and theresult of the examination is documented. The reasons for acceptance or rejection areexplained.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 opennessof standards as well as definitions of the different classification of standards. In addition tothis, the subject of SAGA compliance of eGovernment applications is dealt with.Chapter 3 describes the architecture model for eGovernment applications. This model wasalso adopted for the description of eGovernment in Germany. Accordingly, the followingchapters 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 thestandards referred to in chapter 8. Appendix C finally presents a list of the abbreviationsused in SAGA.49 Refer to http://www.kbst.bund.de/saga
  • 19. SAGA 4.0 192 Fundamentals of SAGA2.1 Scope of validity and binding effect of SAGAAround 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. G2C – Government to Citizen G2B – Government to Business G2G – Government to Government (Interaction between the (Interaction between the (Interaction between administrations) administration and citizens) administration and business) • BA: Job exchange • BA: Job exchange • KBA: Central traffic and motor • DRV: Calculation and payment of • BeschA: Procurement vehicle register pensions • BBR: Procurement for • BBR: Procurement for construction • BMAS: Provision of information construction and civil engineering and civil engineering projects • DWD: Weather forecast and projects • BMF: Management of Federal- meteorological advice • BMBF: Project-related subsidies Government properties • BpB: Provision of information and • BMWi: Subsidy programmes • BAköV: Further training and order handling education • BZR: Federal Central Criminal Register Figure 2-1: Selected Federal Government servicesSAGAs scope of validity covers the federal administration and software systems withinterfaces between federal authorities and federal-state and/or municipal authorities inorder to support the services listed above.SAGA includes recommendations concerning standards and architectures foreGovernment applications. The term "eGovernment applications" refers to softwaresystems which are used to fulfil services of the Federal Government or which activelysupport the fulfilment of such services. In the case of systems with no direct interfaces witheGovernment, migration is recommended on condition of a positive outcome of the cost-to-benefit analysis. Whenever possible, the standard software51 to be bought should beprimarily products or product versions which are compatible with SAGA recommendations.Furthermore, SAGA considers only those areas which have a major influence on theaforementioned objectives52 rather than all the elements of a technical architecture.The Federal Ministry of the Interior recommends that SAGA be considered in invitations totender for eGovernment applications for the federal administration in the mannerdescribed 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 configured52 Refer to section 1.3 "Aims" on page 12.
  • 20. 20 SAGA 4.0The federal ministries lay down rules for the binding effect of SAGA within their areas ofcompetence.2.2 Minimum requirements with regard to the openness of standardsOne aim of SAGA is the use of open standards in eGovernment applications, refer to section1.3 "Aims" on page 12. There are currently many different definitions for an "openstandard", however, there is no one generally valid definition accepted by all. Variousstandardization committees have issued definitions which are essentially the same in termsof how a standard emerges, its documentation and application. However, opinions do differwhen it comes to the type of standardization organization and the license cost system of astandard. 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 remaina practice-based recommendation. This is why "minimum requirements" were defined forthe openness of standards which will also serve as an evaluation basis for accepting orrejecting a standard in SAGA.The minimum requirements for the openness of standards for acceptance in SAGA aredefined 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 standards2.3.1 Classification in SAGAStandards are divided into three categories. Competing standards which are not statedshould 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. These53 Refer to section 2.2 "Minimum requirements with regard to the openness of standards" on
  • 21. SAGA 4.0 21standards may not yet have proven their worth in practical application or do not meet allthe 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 tothe standards under observation, such standards under observation can be used ineGovernment applications. Only in justified exceptional cases should preference be givento standards under observation over higher classified alternatives. Recommended:Standards are recommended if they have been tried and tested in practical application butif 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 andinvestment security warranted.In the event that no competing mandatory standards exist besides recommendedstandards, deviations from the recommended standards are permitted in justified,exceptional cases only.Competing standards can be recommended parallel if they have clearly different fields ofapplication. The standard which is best suited for the given application must be adopted insuch cases. Mandatory:Standards are mandatory if they have been tried and tested in practical application andrepresent the preferred solution. They are established on the market and meet all the aimsof SAGA. Such standards must be observed and applied with priority.Competing standards can be mandatory parallel if they have clearly different fields ofapplication. In such cases, the standard which is best suited for the given application mustbe used.In the event that mandatory and recommended standards or standards under observationexist parallel, the latter - i.e. standards under observation - should only be adopted injustified, exceptional cases.A standard classified as mandatory does not necessarily have to be used in everyeGovernment application. A mandatory standard only should be adhered to if the use of thetechnology or functionality related to this standard is necessary or reasonable in view of therequirements of the specific application.2.3.2 Extended classification of standardsThree lists for the extended classification of standards were introduced with the publicationof SAGA 2.0 on the SAGA homepage at http://www.kbst.bund.de/saga-standards. Nostandards other than those on the Right of Continuance List (former Grey List) may be givenpreference over the standards classified in the SAGA document (mandatory, recommended, page 20.
  • 22. 22 SAGA 4.0under observation) – however, only if existing systems, in which these standards are alreadyused, are being upgraded.List of SuggestionsThe List of Suggestions (former White List) was created in order to respond promptly to newdevelopments and to be able to communicate these externally for information. During thecourse of developing the SAGA document further, the List of Suggestions is an importantbasis for including standards in SAGA.Standards are listed in the List of Suggestions if proposals and ideas for their inclusion inSAGA were submitted to the SAGA authors, if they have potential for use in eGovernmentapplications 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 expertgroup. The result of this evaluation can mean acceptance of the standards in the nextversion of the SAGA document, relocation to the Negative List (former Black List) or to theRight of Continuance List (former Grey List) or also remaining on the List of Suggestions, sothat 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 areagain examined with regard to their suitability for inclusion.Right of Continuance ListStandards are added to the Right of Continuance List (former Grey List) if they are no longerincluded 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 cancontinue to be used. These standards, however, should no longer be used for neweGovernment applications.Negative ListWithin the scope of the SAGA discussion, certain standards that were already rejected in thepast are repeatedly proposed for inclusion. The Negative List (former Black List) was set upin order to make the results of these discussions transparent and to identify those standardswhich 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 theSAGA authors and the SAGA expert group. The standards should not be used in new orexisting eGovernment applications. Their use is only permitted if a parallel SAGA-compliant solution exists. Images, for instance, can be made available in BMP format eventhough 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 inareas that were previously criticized, the version number of the negative-listed standardmust be stated. Now nothing stands in the way of the new version being included in SAGAvia the List of Suggestions (former White List).
  • 23. SAGA 4.0 232.3.3 Life cycles of standardsBesides the standards classified in SAGA, refer to section 2.3.1 on page 20, other standardsare recorded in three different lists, refer to section 2.3.2 on page 21. Whilst theclassification of standards as "mandatory", "recommended" and "under observation" isdefined and updated in the SAGA document, presentation and ongoing updating of thestandards 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 inFig. 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 definedin 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. 24 SAGA 4.0 SAGA DOCUMENT SAGA HOMEPAGE Mandatory Negative List (former Black List) 6 7 10 9 8 Recommended Right of Continuance List (former Grey List) 5 3 2 Under observation 4 List of Suggestions (former White List) 1 New standards Figure 2-2: Lifecycles of SAGA standards6 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 cannot only move one step along the lifecycle previously presented, they can also retain theirstatus or pass through several steps in one go.
  • 25. SAGA 4.0 252.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 conformance2.4.1 Definition of conformanceThe SAGA conformance of an eGovernment application54 is evaluated on the basis of themodels, procedures and standards described in SAGA:a. Consideration of standardized process modelsb. Consideration of standardized data modelsc. Compliance with the standards and architectures described in SAGAd. Use of existing one-for-all offers (OFA offers)55In order to be able to make a comprehensive statement concerning the SAGA conformanceof an eGovernment application – especially in conjunction with the implementation ofcomplex, specialized processes – an application should first be broken down into individualunits56 before evaluating its conformance. Software units developed internally aredistinguished here from units (products) developed externally. In order to evaluate theSAGA conformance of products, importance is primarily attached to communicationinterfaces, data interchange formats and security. In the case of in-house developments,the technologies for creating models and implementing the application are additionallyrelevant as is the use of OFA offers.The SAGA homepage provides a blank declaration of conformance and an example of acompleted declaration of conformance with checklists for software units and externalunits57. The checklists feature topical areas which are relevant for in-house developments orfor products, respectively.54 The term "eGovernment application" is used as a general term for any IT system which provides eGovernment services of the Federal Government. With regard to the definition of the term "eGovernment service", please refer to section 4.1.2 "The term "service" in eGovernment" on page 35.55 Refer to section 6.3.6 "Reuse and integration of OFA offers" on page 76.56 According to the XT process model, a unit is the system element on the very top of a hierarchical structure; refer to http://www.v-modell-xt.de/57 Refer to http://www.kbst.bund.de/saga-konformitaet
  • 26. 26 SAGA 4.0 eGovernment application SW unit 1 External unit 1 ... Unit n (In-house (product) (...) development) Check-list for SW Check-list for ... Check-list for units developed external units ... in-house (products) Figure 2-3: Layout of the SAGA declaration of conformity and checklistsWhich specific standards from the relevant topical areas have to be used to ensure SAGAconformance varies depending on the area of application and the functional scope of theapplication. For instance, definitions for creating information services for mobile phonesand/or PDAs are only relevant for SAGA conformance if these terminal devices are to beused by the eGovernment application. SAGA conformance is hence achieved by applyingthe particular subset of all SAGA standards which is relevant for the specific eGovernmentapplication.2.4.2 SAGA conformance in invitations to tenderIn order to avoid neglecting the customers concrete requirements when it comes to SAGAconformance 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 criteriain its contracting documents.A general demand for SAGA conformance is not enough in order to achieve the goals ofSAGA. Due to the complexity of the document, a general demand leaves too much room forinterpretation and misunderstanding. This makes it difficult for the supplier to fulfil therequirements 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 thecustomer and the supplier, refer to Fig. 2-4. This process limits the room for interpretationand reduces misunderstandings. The concrete demands can be checked and thus create asound basis for the contract between the customer and the supplier. Specifying theconcrete details of demands also prevents offers from becoming unnecessarily expensive.
  • 27. SAGA 4.0 27 CUSTOMER SUPPLIER Project started Create contracting Send documents 1 documents with criteria related to SAGA Send offer Write offer including replies concerning 2 customer criteria related to SAGA Evaluate offer Award contract 3 considering supplier replies concerning SAGA criteria Hand over application Implement job and subsequently complete SAGA 4 conformance declaration Perform acceptance 5 and check SAGA conformance Project completed Figure 2-4: Declaration-of-conformance processThe process essentially comprises five steps which are briefly described below.Step 1: Including aspects of SAGA conformance aspects in the contract documents of aninvitation to tenderThe customer puts together a series of exclusion and evaluation criteria which cover all therelevant aspects of the desired application. The criteria group example which can bedownloaded from the SAGA homepage can serve as a template58. This criteria groupexample contains possible criteria which can result from the application of SAGA. Thecustomer must select or supplement the criteria which are relevant for the project. Thecriteria group example contains explanatory information which makes selection easier.The customer must also decide whether criteria are defined as exclusion criteria or asevaluation criteria. Exclusion criteria should be used very moderately because they reducethe number of bids. Alternatively, high-weighted evaluation criteria should be taken intoconsideration.Step 2: Supplier response to the SAGA conformance criteria group within the scope of offerpreparationThe supplier responds to the "SAGA conformance" criteria group within the scope of hisoffer preparation. He can base his offer on a completed criteria group example which canalso be downloaded from the SAGA homepage59. This criteria group is filled in, it serves as58 Refer to http://www.kbst.bund.de/saga-konformitaet59 Refer to http://www.kbst.bund.de/saga-konformitaet
  • 28. 28 SAGA 4.0an example and contains explanatory comments which are helpful when filling in aconcrete criteria group.Step 3: Supplier examination of the details concerning SAGA conformance, evaluation of therespective criteria within the scope of offer evaluationThe customer checks the criteria groups completed for the offers received. Offers which donot fulfil the customers 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 applicationIf the supplier has implemented the eGovernment application, he declares the SAGAconformance of the application in writing. To do so, he completes the declaration ofconformance for the application and attaches the checklists for the individual units of theapplication. Deviations from the commitments made in the completed "SAGAconformance" criteria group should be discussed with the customer at an early point intime 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 bedownloaded from the SAGA homepage60. Blank templates of a declaration of conformanceare also available on this homepage.Step 5: Examining SAGA conformance on the basis of the offer and the declaration ofconformance by the supplier within the scope of acceptanceDuring acceptance, the customer can evaluate SAGA conformance on the basis of the "SAGAconformance" criteria group completed by the supplier in the offer and the declaration ofconformance issued after implementation. This evaluation is as easy as possible thanks tothe specific details of the offer. If the application deviates from the commitments made inthe 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 withtechnologies 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) ispossible without violating SAGA conformance61.A lack of alternativesThe 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 mandatoryor 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
  • 29. SAGA 4.0 29Special functions and application areasIf, 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 thestandards in order to find out the circumstances under which the lower classified standardscan be given preference. The reasons for this are, first and foremost, when extendedfunctionality62 is required, or special areas of application63. The use of standards "underobservation" should be particularly well considered because no investment security hasbeen established for these standards and because it is not warranted that they will remainin effect. With the next version of SAGA, such standards can already be featured on theNegative List (former Black List).Parallel offersIf SAGA-conformant standards are used as depicted above, additional standards and/orformats can be used which are not listed in SAGA or which have a lower classification inSAGA. If, for example, spreadsheet data64 is made available in CSV format, the same data canbe additionally made available in other formats, such as Microsoft Excel, without violatingSAGA conformance.Use of external units (products)In the case of external units (in contrast to software units developed in-house), the focus isplaced on communication interfaces, data interchange formats and security. Technologiesfor process modelling, data modelling, application architecture and the use of OFA offers65do not form part of the checklists for the SAGA declaration of conformance. In the case ofcertain units, customers should check whether the corresponding technologies should bespecified in order to make use, for instance, of existing infrastructures for operating theunit and to achieve synergies with other eGovernment applications.Technologies beyond the focus of SAGAOf course, topics for which SAGA does not make or has not yet made any statements have noeffect on the evaluation of the SAGA conformance of an eGovernment application.2.4.4 Responsibility for conformanceThe public agency responsible for an eGovernment application is also responsible forensuring conformance with SAGA. The public agencies are also responsible for examiningways 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 10963 Refer, for instance, to the descriptions of Unicode coding in section 8.6.2 "Character sets" on page 10664 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. 30 SAGA 4.0Due 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 homepage66of the Federal Ministry of the Interior.2.4.5 Migration for conformanceTransition phaseSAGA is undergoing continuous development and regular updating so that it can beadapted to meet new requirements. This is why individual eGovernment applications,which are orientated towards an older SAGA version67 , may temporarily not comply withthe current SAGA version.Migration plans should be developed for non-conformant applications if the result of thecost-to-benefit analysis is positive. This may only be the case where major enhancements ofthe application are concerned.Measures to achieve conformanceThe 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 aresubject 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.
  • 31. SAGA 4.0 313 Architecture model for eGovernment applications3.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 standardizedas ISO/IEC 10746-3:1996, is the approach of choice for describing complex, distributedeGovernment applications. The discussion on the application is broken down into differentviewpoints in order to reduce the complexity of the overall architecture and this in turnmakes it easier to understand and master an application. The object-orientated paradigm70is the basis for the RM-ODP. Object orientation promotes clear-cut structures, re-usabilityand 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 systemsand applications. SAGA suggests, but does not dictate, the use of RM-ODP to describeeGovernment applications.69 Reference Model of Open Distributed Processing, refer to [ISO 1996]70 Refer to [KBSt 2007], section 3.3.1
  • 32. 32 SAGA 4.0 Enterprise Viewpoint Purpose, use area and rules Information Computational Viewpoint Viewpoint Data structure System elements and semantics eGovernment and interfaces Hardware and Standards and infrastructure technologies Engineering Technology Viewpoint Viewpoint Figure 3-1: Viewpoints according to RM-ODPFurthermore, the SAGA document itself is structured according to the RM-ODP model. Theresult 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 fundamentalelements: the organizational structure of eGovernment in general as well as theorganizational models of the application. This is where the overall environment for thesystem and its purpose are described. Furthermore, the requirements for the system,relevant constraints, executable actions and data processing policies are defined from theorganizations or enterprises point of view. This exercise includes a definition of theprocedures, their rules, as well as the actors and their roles in the process.The efficiency of information technology depends heavily on an integrated view. Thismeans that instead of focusing on information technology, the technical application isprimarily regarded and described as a process.Services can and should be described in the form of technical process models. This meanslooking at all the work steps from start to finish, i.e. from the inquiry by the "customer"
  • 33. SAGA 4.0 33(citizen, business, other public agency, etc.) to the rendering of the service. On their firststage 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 toa. Re-usabilityb. Simplicityc. The possibility to be described by existing process definitions.The KBSt website provides a guideline for process and data modelling71 and supports thosein charge during process modelling. Support is also available from the "WorkflowManagement, Processes and Organization" (WMPO CC) competence centre72 at the FederalOffice for Information Technology (BIT).Chapter 4 "Enterprise viewpoint: Fundamentals of eGovernment" on page 35 describes theenterprise 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 enterpriseviewpoint for concrete eGovernment applications.3.3 Information viewpointThis viewpoint determines the structure and semantics of the systems information.Furthermore, the activities (status changes) which can be carried out with the informationobjects 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 dataidentities (such as the application) and for the data to be exchanged between processes orapplications.Data models should always be checked with a view toa. Re-usabilityb. Simplicityc. The possibility to be described by existing data modelsThe KBSt website provides a guideline for process and data modelling73 and supports thosein charge during data modelling.Chapter 5 "Information viewpoint: Standardization of data models" on page 55corresponds to the information viewpoint of German eGovernment and should beconsidered when creating own data models. Section 8.3 "Data models" on page 96 classifiesthe 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. 34 SAGA 4.03.4 Computational viewpointThis viewpoint breaks an application down into logic, functional elements which aresuitable for distribution. The result is objects with interfaces via which they offer theirfunctionality and/or use the functionalities of other objects.Interaction takes place in the form of local and remote communication between theelements. Secure interaction may be required here. The protection aims are described insection 8.1.2.1 "Protection aims" on page 92.The applications are also broken down into layers in which each of the individual elementscan be found.Chapter 6 "Computational viewpoint: Reference software architecture" on page 65provides a description of a general computational viewpoint of eGovernment applicationswhich 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 eGovernmentapplications, such as systems and services. In chapter 8 "Technology viewpoint: Standardsfor IT architecture and data security" on page 91, SAGA defines standards and technologiesfor implementing the computational viewpoint and for creating secure interactionbetween system elements.3.5 Engineering viewpointThe engineering viewpoint describes the system support needed to permit the distributionof objects from the computational viewpoint. This includes system elements for executingobjects, such as computer hardware and communication infrastructures, as well as all kindsof 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 eGovernmentapplications of federal agencies. The corresponding viewpoint of a concrete online servicecan 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 tosupport 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 methodsfor the IT architecture and data security.
  • 35. SAGA 4.0 354 Enterprise viewpoint: Fundamentals of eGovernmentIn line with the definition of the enterprise viewpoint in chapter 3 "Architecture model foreGovernment applications", the fundamentals of eGovernment in Germany will bedescribed in the following as the overall environment for the standardized introduction ofeGovernment applications.Besides this general approach, the process level in eGovernment will also be addressed inmore detail. The process models are the starting point for deriving inter-agency moduleswhich are to be integrated into eGovernment applications.4.1 Definitions of eGovernment in Germany4.1.1 The term "eGovernment"eGovernment (electronic Government) is understood to be the use of electronicinformation and communication technologies in order to involve customers ofadministrations in the activities of government and the public administration74. The aim isto offer customers of administration services, i.e. citizens, businesses and theadministration itself, electronic access to administration services and information. Thepossibilities offered by these technologies are very diverse. They range from themodernization of administrative processes using electronic workflow management to theprovision of administrative information using public agency portals on the Internet and tocomplex transactions and interactive electronic web services for citizens.Aspects of eDemocracy are not explicitly addressed in this context because the governmentis assumed to pursue different approaches towards its roles in relation to citizens andbusiness. As far as eGovernment is concerned, citizens and business are the clients ofadministrations and governments. eDemocracy is based on the concept of the citizen as thesovereign, 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 orresult of an activity by a public administration which serves the citizen, business or anotherpublic agency75. A service includes processes, obligations and burdens, such as therecognition as a conscientious objector, applications for unemployment benefits, or thegranting 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.pdf75 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. 36 SAGA 4.04.2 The philosophy underlying eGovernmenteGovernment opens up new ways for reform and innovation in the pubic administrationusing electronic services and processes. This concerns internal relationships withinadministrations 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 growingpenetration of the Internet, especially in private households, is also leading to a growingdemand for electronic services by government. eGovernment is the response to thisdemand.For citizens, contact with administrations sometimes involves long distances and waitingtime. Compared to this, Internet-based communication and transactions can help saveconsiderable amounts of both time and money. This means that in future many citizens willfrequently be able to handle their administration matters from the comfort of their ownhomes. Internet portals simplify access to public information and services.In order to tailor the service offered by administrations to demand, citizens must remainfree to choose which form of access to the administration they wish to use. Access to thepublic 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 aspossible and processed in a standardized manner so that administration work can beshaped as efficiently as possible. Moreover, Internet barriers and restrictions posed by theInternet 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 differentfields, e.g. for certification, licensing and approval procedures, as well as proceduresrelated to the customs and excise and tax administration.On a global scale, all leading industrialized nations introduced powerful eGovernmentservices in recent years. eGovernment is today a location factor. The national and EU plansfor expanding eGovernment services in the years to come are hence fully orientatedtowards boosting benefits for citizens and especially for companies, as well as reducing thecost of administration services. In some federal states, the focus is being placed on thedemand-based expansion of eGovernment services and on increasing the number of users.The beginning integration of administration and business processes along value chainsmakes 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]
  • 37. SAGA 4.0 37The availability and quality of electronic administration services is hence a factor not to beunderestimated in the global competition to entice companies to relocate or set upbusiness. Boundary conditions must be attractive and barriers for companies must be keptas low as possible.4.3 Strategic goalsThe philosophy addressed in the previous section forms the main objective for the strategicgoals of eGovernment for Europe and Germany. In order to reach these goals, the publicadministration must be modernized. A general overview of the programmes, strategies andmeasures pursued by the Federal Government here with a focus on human resources,administration management, organization and eGovernment can be found athttp://www.verwaltung-innovativ.de/. The following section presents the FederalGovernments central programmes and strategies which, in the years to come, will pave theway for the further development of eGovernment on Federal, federal-state and municipallevel in Germany.4.3.1 eGovernment 2.0 – A Federal Government programmeThe top priority of the eGovernment 2.0 programme77, which was adopted by the FederalCabinet in September 2006, is to make the federal administration fit for a service-orientatedinformation society. The needs of users of eGovernment applications are to be focused onmore in the future – for instance, users are to be enabled to communicate with publicagencies without the fear of identity fraud or electronic annoyance78. Accordingly, thefederal administrations Internet offering is to be expanded by 2010, both in terms of qualityand quantity. The programme is being coordinated by the Federal Ministry of the Interior incooperation with the different federal ministries.The goals listed are supported by measures in four fields of action:a. Portfolio Demand-orientated, quality and quantity-related expansion of the eGovernment offering by the Federal Government (e.g. Arbeitsagentur-Online [online job agency]79)b. Process chains Media-consistent electronic process handling between business and the administration using integrated process chains, as well as standards for interface and exchange formats (e.g. secure foodstuff chain80)77 Refer to http://www.kbst.bund.de/e-government/78 National Plan for Information Infrastructure Protection (NPSI): Federal Ministry of the Interior, 2005; http://www.bmi.bund.de/, navigation topics "Themen A-Z" [A-Z topics] > "Informationsgesellschaft" [Information society] > "Sicherheit in der Informationstechnik" [Security in information technology] > box: "Links zum Thema" [Links to the topic]79 Refer to http://www.arbeitsagentur.de/80 IT FoodTrace research project: http://www.itfoodtrace.de/
  • 38. 38 SAGA 4.0c. Identification Launch of electronic identity management using future functions and applications, e.g. on the electronic ID card (ePA)81 as well as the development of eIdentity strategiesd. Communication A secure communication infrastructure in the form of portals for citizens, businesses and administrations (e.g. citizens portals82)4.3.2 Deutschland-Online - The joint eGovernment strategy of the Federal Government, federal-state governments and municipalities.The aim of Deutschland-Online (DOL)83 is to create a fully integrated eGovernmentlandscape in Germany, so that electronically captured data can be exchanged between theadministrations of the Federal Government, federal states and municipalities in aconsistent manner and across all levels. This strategy is based on the following principles:a. One For All (OFA) The individual participants from Federal Government, the federal states and municipalities develop model solutions which are used by the other participants.b. Responsibility of lead units The main responsibility for a DOL project lies in the hands of the proposing public agency which is also in charge of the creation of a tenable business model and its implementation.c. Transparency of standards – competition between products. Transparent standards and process models are used to define a framework for which various products can be selected, hence promoting interoperability between different products.In order to implement the strategic goals, the heads of federal and federal-stategovernment adopted the Deutschland-Online action plan in June 2006 with six prioritizedprojects and extended this in June 2007 with the IT implementation of the EU servicesdirective84:Infrastructure85The Federal Government, federal states and municipalities currently have differentnetwork infrastructures wich are not connected to each other and hence constitute islandsolutions. This means that for a host of public agencies it is not always possible to exchangedata with other agencies in a reliable, simple and secure manner. The establishment of a81 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]
  • 39. SAGA 4.0 39communication infrastructure for Germanys public administration is designed to create auniform network and hence achieve secure electronic communications between publicagencies on Federal, federal-state and municipal level.StandardizationThe purpose of the DOL "Standardisierung" [Standardization] project is to support andcoordinate the development and provision of technical standards for electronic datainterchange (XÖV standards), so that electronic administration processes can beimplemented in an efficient and uniform manner. For this purpose, the project forsupporting the XÖV projects offers public administrations coordinated and harmonizedmeasures, such as development methods, standardized data models, tools and technicalinfrastructures, along with advisory services and PR work.86IT implementation of the EU services directive87The goal of the project is to simplify and accelerate electronic administration processes inGermany 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 serviceactivities via a uniform online contact, irrespective of their nationality or of the memberstate in which they are currently located. By mid-2008, a model for the IT implementationof 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 bedefined, the IT support required for media-consistent process handling is to be described, asuitable IT architecture developed and technologies proposed with a view to the interfacesrequired.Registration services89The 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 officesand used in approx. 114 million business transactions every year – for instance to provideinformation. As of 1 September 2006, the Federal Government was given the sole legislativecompetence of registration services as part of federalism reform. The aim is to create aFederal Identity Register (BMR) in addition to the municipal register in order to simplifyregistration procedures for citizens, to make use of the identity register more efficient andless expensive for businesses and administration, to improve the quality and up-to-datenessof the registration data and to make it possible to create nationwide, uniform onlineservices.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. 40 SAGA 4.0Motor vehicle registration services90Citizens and the business sector can currently perform certain tasks in conjunction with theregistration, de-registration and re-registration of motor vehicles online (e.g.: enteringvehicle 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 vehicleregistration which offers citizens and the business sector a consistent process via theInternet without media inconsistencies.Civil status registration services91On 23 February 2007, the "Gesetz zur Reform des Personenstandsrechts (PStRG)" [LawReforming Civil Status Law] was ratified permitting, as of 1 January 2009, electronicregisters and making these, as of 1 January 2014, mandatory. The aim of the project is todevelop an electronic procedure for civil status registration services based on the Law andto use this to implement pilot projects for civil status registration services in certain federalstates and also to enable citizens to obtain register information and apply for documentsonline. Part of the project also involves automated communications between the civil statusregister and other public agencies in response to requests for information. This exchange isto support the "XPersonenstand" data format to be developed.Other Deutschland-Online projectsIn addition to the previously described projects, there are a number of other projects beingimplemented within the scope of Deutschland-Online92:a. Official statisticsb. BAföG (Federal Education Assistance Act)c. Clearing housesd. German Forum for Electronic Signatures and Chip Cardse. Geodataf. Business modelsg. Commercial registerh. Judicial registeri. VEMAGS (Procedure management for bulk and heavy transports)j. Internet portals / Responsibility finder projectk. 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]
  • 41. SAGA 4.0 41l. XSozial [XSocial]4.4 Organizational requirementsThe implementation of eGovernment in Germany is bound by organizational requirementswhich must be taken into consideration. The most important of these requirements aredescribed in the following.4.4.1 Cross-administration interactionFederalism in GermanyWhen implementing eGovernment, federalist states like Germany must face the problemsof a de-centralized administration structure because the de-centralized administrativeunits are largely independent of central government.Whilst the Federal Government holds most of the legislative power, it is the federal statesand municipalities that are mainly responsible for implementation. The direct federaladministration performs national tasks. Only those functions specifically defined in theGrundgesetz93 [German Basic Law] (articles 87-89) have an underlying administrativestructure of their own, such as the Foreign Service, the Federal Armed Forces, the FederalPolice or the Federal Revenue Administration. Besides these functions, there are othernational tasks which are typically performed by special administrative agencies without anunderlying administrative structure of their own (e.g. the Federal Criminal Police Office, theFederal 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 Governmentb. 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 FederalGovernment commissions external administrative bodies as independent legal entities.These legal entities, in their capacity as corporate bodies, institutions and foundations ofthe indirect federal administration, are independently responsible for their fields ofcompetence throughout the territory the Federal Republic of Germany and report to aministry.Comparable structures exist in the individual federal states. Furthermore, cities, districtsand municipalities constitute the third administrative level in their capacity as territorial93 Basic Law of the Federal Republic of Germany [German Constitution] (GG): http://www.gesetze-im-internet.de/bundesrecht/gg/
  • 42. 42 SAGA 4.0communities with autonomous administrations which also perform their own tasks inaddition 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 tendto expect standardized and consistent eGovernment services, refer to Fig. 4-1. Fed. Fed. Gov. Municipalities States § G2G § G2G § Agency Agency Agency G2G G2G § G2G § Agency Agency G2C G2B € Citizens Business Figure 4-1: eGovernment interaction in GermanyWhat is generally needed is cooperation, networking and coordination within andbetween administrative levels. A first step taken at federal level was the implementation ofthe Informationsverbund Berlin-Bonn (IVBB)94 [Information Network Berlin-Bonn] which isan intranet for the supreme federal authorities. The upgrading of this network to form theInformationsverbund der Bundesverwaltung (IVBV)95 [Federal Administration InformationNetwork] will connect all the federal authorities to a secure, closed network – thisconstitutes an enormous challenge on both a technical and organizational level96.With Deutschland-Online as the joint national eGovernment strategy of the FederalGovernment, the federal states and municipalities, an expanded action plan was presentedin 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
  • 43. SAGA 4.0 43Germany as a member of the European UnionAs a member of the European Union (EU), the Federal Republic of Germany is increasinglybeing required to implement cross-border eGovernment services like those demanded inthe EU services directive. The goal is to create a uniform, single market in the EU and to offerall citizens and businesses the same opportunities and rights.As shown in Fig. 4-298 , national services have to be offered more to citizens, business andpublic agencies of other member states. Cooperation with the EU administration is also tobecome more important in the future. MEMBER STATE A MEMBER STATE B National eGovernment interaction Cross-border eGovernment interaction Citizens G2C Citizens G2C € G2B € Business Business G2B § § § G2G G2G Agency Agency G2G Agency § EU Agency ADMINISTRATION Figure 4-2: National and cross-border eGovernment interactionCitizens and businesses using such cross-border eGovernment applications do notdifferentiate between the different areas of responsibility of national administrations,instead they expect a uniform, multilingual and consistent eGovernment offering betweenthe member states. This means that in future it must be possible, for instance, for a buildingcontractor in Italy wishing to relocate to Spain to be able to carry out the requiredcommunications with public agencies electronically from Italy. The contractor onlycommunicates with one contact partner in this context. The necessary interaction betweenthe 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
  • 44. 44 SAGA 4.0border eGovernment application without the contractor being aware of this or having tocontact 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 vehicleregistrations. The EU services directive99 provides the corresponding framework for theimplementation of these applications.4.4.2 Optimization of administrative processesThe successful introduction and implementation of eGovernment calls for the examinationof grown processes. Existing rules, processes and structures must be adapted and simplifiedin a suitable manner taking technical and legal circumstances into consideration. The mereelectronic implementation of conventional procedures seldom leads to optimization.Existing administrative processes are partly the result of historical developments and havebecome complex over the course of time as a result of many changes. The followingmeasures are hence recommended before special applications are implementedelectronically.a. Simplification of processes and proceduresb. Deregulationc. Shortening of process chainsd. Reduction in the number of interfacese. Avoiding iterationf. Reduction in cycle and dead times100First steps towards reducing red tape were designed to simplify processes and legalregulations for administration services. This is why Deutschland-Online101 covers servicesthat concern several administration levels. The Federal Governments "ZukunftsorientierteVerwaltung durch Innovationen"102 [Future-orientated administration through innovation]programme triggers level-spanning processes which lead to an open dialogue on a jointvision for a future-enabled, network-orientated administration in Germany.4.4.3 Qualification of staffThe use and updating of standards, along with the development, operation and correcthandling of IT-supported systems, calls for the continuous exchange of information andtraining. Many employees in the public sector are highly motivated when it comes tosupporting eGovernment. This important asset must be exploited and increased in theinterest of implementing eGovernment. This means that intensive training must be carriedout for employees. Moreover, the administration must be made more attractive for ITexperts.99 Refer to section 4.5.4 "EU services directive – Creating a single EU market" on page 48100 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/
  • 45. SAGA 4.0 454.4.4 Involvement of usersThe use of eGovernment is strongly dependent on customer acceptance of the servicesoffered. Full utilization of the savings potential of eGovernment is contingent upon theonline services provided being accepted and used by potential users. Expectations amongcitizens, companies and public agencies as the specific target groups need to be identifiedon an ongoing basis. The service portfolio and the service rendering process must beadapted to these expectations.4.5 Legal frame of referenceIn addition to the strategic goals and organizational frame of reference, legal guidelinesmust also be considered. The most important of these will be described in the followingalong 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 servicesdirective. A detailed description of the legal adjustments implemented can be found in theFederal Governments E-Government-Handbuch103 [eGovernment manual].4.5.1 Electronic signaturesElectronic signatures allow users of eGovernment applications to have themselvesauthenticated104. Sensible, practical and timely legal adjustments will make it possible foreGovernment to shape administrative processes efficiently and without mediainconsistencies.Legal adjustmentsThe legally binding nature of electronic communications is a crucial success factor for theimplementation of eGovernment. What is hence needed is a digital solution for a signaturewith legally binding effect, i.e. the qualified electronic signature. Contrary to a simple oradvanced electronic signature, a qualified electronic signature offers the highest degree ofelectronic replication of a handwritten signature. The legal adjustments required to enablethe use of electronic signatures and to place these on the same standing as a hand-writtensignature have been completed in Germany. Besides amendments to the Signaturgesetz[Act on Digital Signature] to comply with European requirements, the electronic signaturehas also been integrated into the relevant blanket clauses in administrative and privatelaw105.Dissemination of the electronic signatureThe dissemination and acceptance of qualified electronic signatures has been slow up tonow due to the still prevailing disproportion between benefits and costs. For instance,103 eGovernment manual: http://www.bsi.bund.de/fachthem/egov/6.htm, chapter II, module: "Legal frame of reference for eGovernment"104 Refer to section 8.5.4 "Technologies for authentication" on page 104, section 8.10 "Electronic signature" on page 133 and section 8.10 "Electronic signature" on page 133105 For information concerning the legal basis for the electronic signature, please refer to http://www.bsi.bund.de/esig/
  • 46. 46 SAGA 4.0qualified electronic signatures are only used up to now in a few mass processes andadministration areas, for example, in invoicing.The reasons for this are mostly related to security in the application of signatures andsignature cards, the lack of interoperability between different signature applications, aswell 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 qualifiedelectronic signatures106. These products comply with the necessarily high securityrequirements of the Signaturgesetz107 (SigG) [Act on Digital Signature] and theSignaturverordnung108 (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 havethe signature key regularly renewed) is a factor for administrations which, compared to thebenefits, 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 andadded value of electronic signatures. First practical applications show that smartcards areparticularly attractive for citizens if they can use them for both private-sector and publicservices.Federal Government initiatives and projects in the field of electronic signaturesThe signature initiatives and projects of the federal administration are to be more closelycoordinated with each other in the future in order to promote dissemination andacceptance, especially in conjunction with signature cards. The following cases areexample of projects by the federal administration dealing with the use of signatures andsignature 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 chip106 Federal Network Agency (BNetzA): http://www.bundesnetzagentur.de/enid/Elektronische_Signatur/Produkte_pi.html107 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/
  • 47. 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 besubsequently available for any de-centralised purpose and use.However, when electronic data is interchanged within and between public agencies, dataprotection requirements must be considered and implemented by way of suitable technicaland organizational measures. Personal data, in particular, may not be gathered, processedor disclosed for any purpose other than the use explicitly contemplated by law.The Federal Governments E-Government-Handbuch [eGovernment manual] includes aseparate module113 with comprehensive information concerning the issue of data-protection-compliant eGovernment. Under the title "Technological Data Protection", theFederal Commissioner for Data Protection and Freedom of Information providesorientation aids for certain application cases114, such as the use of document managementsystems or cryptographic methods.4.5.3 Barrier-freedomMore than eight million disabled people, 6.6 million of whom are severely disabled, live inGermany. People with impaired vision and physical handicaps are especially dependent ontechnical aids as a precondition for using the Internet, such as large screens or amagnifying-glass function, Braille line, voice output, etc. In order to optimally enable thesedevices for eGovernment applications, a host of rules and requirements must be consideredduring programming, designing and editing.On 1 May 2002, the new Behindertengleichstellungsgesetz115 (BGG) [Law on EqualOpportunities for the Disabled] came into effect. The aim of this Law is to overcome111 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. 48 SAGA 4.0disadvantages for disabled people, to ensure their discrimination-free participation insocial 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 referencesare to be found in the Ordinance on the Creation of Barrier-free Information Technologypursuant to section 11 of the BGG (Barrierefreie Informationstechnik-Verordnung – BITV116)which came into force on 24 July 2002. This ordinance specifies the Web ContentAccessibility Guidelines117 1.0 (WCAG 1) from 1999 as the technical standard. The BITV isbinding upon public agencies of the federal administration118 since 1 January 2006 andapplies 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 Parliamentand the European Council. The aim of the directive is to reduce red tape in the EuropeanUnion (EU), to promote the cross-border provision of services120 and hence the resultantimplementation of a uniform, single EU market. This directive must be implemented by theend of 2009. Within the scope of electronic procedures, it covers, for instance, the demandsfor: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 by116 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.htm120 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)
  • 49. 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 eGovernment4.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 membersof society. Users on this level merely act as recipients of information. This area is the mostdeveloped level, and almost all public institutions are present on the Internet with anwebsite.Many of these information systems are supplemented by communication solutions withinteractive and participation services which enable the exchange of news, messages andinformation. These services range from simpler solutions, such as e-mail or web-baseddiscussion forums, right through to more complex applications, such as video conferencesystems for telecooperation. In this respect too, the development status of Germanadministrations can be described as being well advanced.Transaction applications feature the highest level of interaction. This area covers theactual provision of services in the public administration. These applications include, forinstance, the electronic receipt and processing of applications or orders as well as theprovision of forms which are filled in on the computer and directly sent to the properrecipient. Electronic payment or tendering systems also belong to this category.Compared to other levels of interaction, transaction services have been implemented to alesser extent up to now. Public Key Infrastructures (PKIs) are an important preconditionwhen it comes to ensuring the authenticity and confidentiality of the data exchangedbetween the different parties. The electronic exchange of documents with legally bindingeffect still involves technical and organizational challenges for public administrations anda satisfactory solution has yet to be found here. Another adverse factor is the currentlysparse 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 ineGovernment 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. 50 SAGA 4.0a. Government to citizen (G2C) Electronic interaction between citizens and the administration – this area also includes non-profit organizationsb. Government to business (G2B) Electronic business relations between the administration and the business sectorc. Government to government (G2G) Electronic relations between different public agencies and public administration institutionsAdministration customers are hence citizens, business and other administrations. The focusin 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 betweenadministrations 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 pureservices, but also rights and obligations. A functional classification of administrations isnecessary as a precondition for standardizing the different types of administrative activity –and hence the possible transactions. Generally valid types of transactional services can beidentified on this basis.Transactional service typesThe German administration can be divided into service and intervention functions basedon responsibilities and legal forms. Different service types can be identified and classified asservice-type and intervention-type services on the basis of the different categories offunctional administrative branches.Services mean that citizens or a business enterprise demand from the administration aservice or benefit, i.e. the citizen or business initiates the process. Services include:a. Applications for government moneyb. Granting of subsidiesc. Subsidy and promotion measuresd. Approval proceduresIntervention is a case where the administration enters into the citizens legal sphere,encroaching upon the citizens freedom or property and/or imposing obligations upon thecitizen. In this case, certain measures are initiated by the administration. Cases ofintervention are:a. Administrative finesb. Criminal prosecution proceduresc. Legal proceedings
  • 51. SAGA 4.0 51d. Collection of taxese. Collection of customs dutiesf. Registration obligationsPublic procurement represents another service type where the government acts as thecustomer for businesses. Contracts for goods and services are subject to definedadministrative procedures.Process-related structure of transaction servicesThe individual transaction types can be broken down further into individual sub-steps. Thesub-steps consist of one or more actions in which different actors are involved. Examples ofsub-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 processmodels for any other transaction type.The sub-steps, which are correlated with each other and explained in more detail in Fig. 4-3and in Table 4-1, are now defined for the services area. Every sub-step involves differentactions and roles which are attributed to different actors. The "application" sub-step, forexample, includes the actions of submitting, transmitting and receiving the application. 1 Information 2 Application Comment and 3 Processing 4 opinion 5 Decision Collection of Payment or 6 administrative disbursement of 7 fees funds Control of fund application 8 Archiving 10 9 Other procedures (e.g. appeal) Figure 4-3: Sub-steps of transaction services
  • 52. 52 SAGA 4.0The applicants 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 officerin charge.In analogy to this procedure, the other sub-steps include further actions and roles whichare summarized in the table below. Sub-steps Actions Roles1 Information Provision of information Editorial team Information request Interested party2 Application Submission of application Applicant Transmission of application (Virtual) post office Receipt of application Officer3 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 office4 Comment and Information evaluation Officer, superior, other officers opinion5 Decision Writing the decision Officer, superior Service of the decision Applicant, (virtual) post office6 Collection of Collection of fees Payor, (virtual) cashiers office administrative fees7 Payment or Payment Payee, (virtual) cashiers office disbursement of funds8 Control of fund Examination of the case Officer, superior, other officers application Request for information Officer, superior, (virtual) post office, other officers Provision of information Payee, (virtual) post office9 Archiving Archiving Officer, records management unit10 Reference to Data transmission Applicant, officer, other public other agencies and officers procedures Table 4-1: Sub-steps, actions and roles of transaction servicesNot every service type defined in the section on "Transactional service types" on page 50must necessarily include all the sub-steps. Depending on the particular process, sub-stepscan be carried out repeatedly during the life of a case.4.7 Modules for the implementation of eGovernment applicationsThe analysis of service types presented in section 4.6 "Processes in eGovernment" on page49 and the related identification of sub-steps, actions and rules can be used as a basis for
  • 53. SAGA 4.0 53identifying functional modules which – given the required configuration possibilities – canbe used to implement different procedures using information technology. The potentialapplications of these modules are dependent upon the quality of the process analysis andthe chosen software architecture123.The following types of modules can be defined in conjunction with the above-describedprocedure.a. User interface The analysis of the different roles leads to a need to develop certain modules which provide functions for accessing the eGovernment application. This includes a standardized, easily recognized user interface for user and role management functions as well as functions for authenticating users in the system.b. Process modules The actions identified are standardized, if necessary, and implemented as a service or system and defined with priorities depending, for instance, on the potential frequency of use in the implementation of the business logic.c. Infrastructure modules Other modules standardize and implement communication with the other components of electronic procedures.The German federal administrations one-for-all services (OFA services) were largely createdwithin the scope of the BundOnline Initiative124 and are described in more detail on the KBStwebsite125 as examples of such modules. The creation of specialist applications on the basisof 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
  • 54. SAGA 4.0 555 Information viewpoint: Standardization of data modelsThis chapter describes as the information viewpoint according to RM-ODP126 howinteroperability between applications is established and/or improved by standardizingdata 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 thestandard for exchanging data127 merely provides a technical basis for this. Although XMLdoes offer the required technical basis, but just like a series of correct words in a certainlanguage do not necessarily make a sensible sentence, XML alone is not sufficient when itcomes to warranting interoperability between applications. In order to be able to ensurethat data can be sensibly interchanged between systems and further processed, it is vitalthat interoperability be secured, not just on a technical level, but also on an organizationaland semantic level.Organizational interoperabilityOrganizational interoperability primarily determines when and why certain data isexchanged. This means that within the scope of organizational interoperability, processeswhich result in the interchange of data are coordinated with a view to legal parameters (e.g.legislation and regulations).Technical interoperabilityTechnical interoperability on the other hand refers to the mere possibility to exchangeinformation. Technical interoperability includes the definition of transmission routes andprotocols (e.g. SOAP, HTTP, FTP, IP, SMTP). The respective standards are referenced in thetechnology viewpoint, for instance in section 8.7 "Communication" on page 121. A commonlanguage 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 interoperabilitySemantic interoperability is given when two systems exchange data in such a manner thatthe data is interpreted in the same way by both communication partners andmisunderstandings are ruled out. This applies not just to the form but also and especially tothe content of the data transmitted.126 Refer to chapter 3, "Architecture model for eGovernment applications”, section 3.4 "Computational viewpoint” on page 34127 Refer to section 8.6.6 "Interchange formats for data ” on page 109
  • 55. 56 SAGA 4.0Semantic interoperability is achieved by defining a uniform presentation form andsemantics for the elements of the XML files exchanged. This definition can be achieved, forinstance, by specifying concrete data models in the form of XML schemas (XSD) or by aRegular Language Description for XML New Generation (Relax NG)128.Moreover, the documentation of the schemas must ensure that the constituent parts areinterpreted 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 theschemas. For instance, in order to make it possible to compare details of occupations, it isnecessary to define certain spelling and wording, because software simply comparing theprofession of an "interpreter" and "translator" will not find any match. If, however, the useof the standard classification of occupations by the German Federal Pension Insurance werespecified, 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 beestablished. The use of such uniform code lists is hence a suitable way to establish semanticinteroperability. In addition to this, the use of code lists also improves the quality of the datato be processed. The codes presented in the selection lists prevent, for instance, wrongspellings 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 inSAGA129 merely secures technical interoperability for the interchange of data betweenapplications. Due to the flexibility of XML, however, this definition alone is not sufficient toensure the standardization of data models. The components of data models especially, forinstance, the address and name of an individual, which occur in many differenteGovernment applications, are presented in a number of ways. There is no semanticinteroperability since the data model in each application can be described in a differentmanner in XML. Standardizing these data models can help to avoid variants and improvethe interoperability of applications based on the same standardized data models. Firstresults with the standardization of data models have already been achieved.Private sector standardization projects have shown that any attempt to achieve full-scalestandardization of data models is usually doomed to fail. The standardization activitieswithin the scope of Deutschland-Online hence focus on communication interfaces forelectronic data interchange in two separate areas. The first area is the standardization ofspecific data models and the second area is the standardization of general data models, so-called core components.Specific data modelsSpecific data models are understood to be those data models which have a strong referenceand which can usually only be used in one area of application even if several public128 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
  • 56. SAGA 4.0 57agencies may be involved in the exchange of specific data. One example of such a datamodel is "XMeld" from the field of citizen registration services.General data modelsContrary to specific data models, general data models – also referred to as corecomponents130 – 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] project5.3.1 Task and project aimNo. 2 of the Deutschland-Online action plan131 finds that binding, uniform standards fordata interchange are a vital precondition for consistent electronic business processes in thepublic administration in Germany.In light of this, the Deutschland-Online "Standardisierung" [Standardization] project wasset up as one of six prioritized Deutschland-Online projects and handed over to the FederalGovernment (represented by the Federal Ministry of the Interior132) and the federal Land ofBremen (represented by the OSCI steering group133) as the lead unit.The purpose of the project is to support and coordinate the development and provision oftechnical standards for electronic data interchange (XÖV standards), so that electronicadministration 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 and municipalities.” on page 38 and also refer to http://www.deutschland-online.de132 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]
  • 57. 58 SAGA 4.05.3.2 XÖV working groupsThe Deutschland-Online "Standardisierung" [Standardization] project is broken down intofour sub-projects: "Bestandserhebung und Gesamtkonzept" [Stock-taking and overallconcept], "Technische Infrastruktur für XÖV" [Technical infrastructure for XÖV], "XÖV-Koordination" [XÖV coordination] and "Kommunikation, Öffentlichkeitsarbeit undVertretung in Gremien" [Communication, PR work and representation in committees]. Amore 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 thedevelopment of uniform methods and concepts for standardizing specific XÖV standardsand 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 forimplementing XÖV standardization projects. The various project phases which an XÖVproject should pass through are described along with the rules for the successfulcompletion 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 "Relationships with other eGovernment documents” on page 13
  • 58. SAGA 4.0 59 XÖV goals Rules for XÖV projects XÖV project types The possibility to use existing, specific modules was examined. Improved interoperability Process-orientated XÖV-expanded The project order includeds a projects benefit assessment. (E projects) Lower project risks Processes were standardized also across administrations. Data-orientated XGenerator was used to create XÖV basic projects Lower costs of XÖV schemas / documentation. (B projects) standardization … supports is a mandatory rule for is an optional rule for Figure 5-1: Goals, rules and project types in the XÖV frameworkThe aim is provide uniform quality and evaluation criteria for the status of current andfuture XÖV standardization projects. Uniform evaluation criteria, on the other hand, are animportant precondition for the binding recommendation of XÖV standards and hence forthe 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, andc. 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 interoperabilitythrough suitable data modelling is becoming more and more important. Data modelling incomplex eGovernment projects poses ever-greater challenges for those in charge of suchprojects. In a first step towards standardized data models, the Federal Ministry of theInterior is supporting developers of data models through measures which are describedbelow, refer also to Fig. 5-2.
  • 59. 60 SAGA 4.0 Guide document Recommendations for action Feedback and assistance Generation of Basics for semantic XML schemas and interoperability documentation Project-specific Project-specific Core Modeller requirements requirements XGenerator 2.0 components Identification of relevant Import of own data models data models XRepository Figure 5-2: Support for data model developers5.4.1 Guideline for developers of process and data modelsOn its website, the KBSt offers a guideline for developers of process and data models138. Thisguideline provides those in charge of projects with practical assistance andrecommendations for action during their day-to-day work, and describes how high-qualitydata models can be developed.The guideline is designed to address the entire process modelling and data modellingcomplex. It also features information on how to prepare modelling, on modelling itself, andon analyzing and optimizing existing models. All these topics are addressed in theguideline 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 iswhere information is gathered on planned, current and completed projects with an XMLreference. Synergies can be achieved and work reduced by making use of informationpublicly available as well as specifications of projects with a similar topic, or by contactingthose 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/modellierungsleitfaden139 Refer to XML Infopoint, http://www.kbst.bund.de/xml-technologie
  • 60. SAGA 4.0 61The main aim of XRepository is to publish specific and general data models140, so that theycan be reused in projects, thus leading to savings and improved interoperability. A focus isalso 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 arekept 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. Specific data General data models models Proposal list for specific Proposal list for general COLLECTION data models data models Quality assurance Rejection REJECTION LIST of rejected data models CATALOGUE Positively rated specific Positively rated general data models data models CONTINUANCE LIST Standardization Rejection Data models to be retained Recommended Recommended STANDARDS XÖV standards XÖV core components Mapping, if necessary Figure 5-3: Standardization process in XRepositoryThe 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. Usersof XRepository are informed that when these models are used, high quality andcompatibility with future standards are not warranted. Despite this, by reusing the modelsfrom the XRepository collection, savings can be made since double work is avoided. Usingmodels from the collection is particularly good when no interoperability with othersystems is required.In order to achieve high quality despite the low requirements for the XRepositorycollection, 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 qualityrequirements141.In the third level of XRepository, the standards, i.e. the XÖV core components (general) andthe XÖV standards (specific), will be included. The standardized data models fulfil the140 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.
  • 61. 62 SAGA 4.0quality requirements of the catalogue. Care will be taken to ensure that no data modelsexist in the catalogue which compete with the standards. A continuance list will be set upfor those models of the catalogue which will be replaced by standards. Data models in thiscontinuance list can still be used. New projects, however, should use the standards. In orderto make it easier to replace established models of the catalogue with standards, migrationinstructions can be provided in XRepository which facilitate the transfer of establishedmodels to XÖV core components or XÖV standards, respectively. Mappings could enablethe use of standards for data interchange without having to internally replace establisheddata models.The use of the standards for data modelling shown in XRepository is recommendedparticularly for those eGovernment applications which involve data interchange acrossagencies 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 repositoriesare being created for their dissemination. On international level, UN/CEFACT is the leaderin the development of core components142. As soon as German standards come into contactwith international data traffic, an exchange with international standardization projectswill 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 toautomatically generate specifications for XML-based data interchanged from UML models.These specifications can be made available in machine-readable form to the softwareimplementations.A specification in this case consists of a number of machine-readable XML schemas anddocumentation for the application developer which is consistent with this. The use ofXGenerator 2.0 avoids the difficult, manual updating of the schemas and thedocumentation which would otherwise be necessary. In the event of modifications of thespecific model, XGenerator 2.0 can be used to automatically generate the new XMLschemas 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 profile144b. Automatic generation and validation of XML schema files from UML modelsc. automatic generation of DocBook files145 from UML models142 Refer to Core Component Library, http://www.unece.org/cefact/codesfortrade/codes_index.htm#ccl143 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.
  • 62. SAGA 4.0 63 Specification developer adds information for the Specialist group UML model generation of schemas and defines the their documentation specific model Documentation XGenerator Refined specific model generates with an XÖV UML profile XML schema Figure 5-4: How XGenerator 2.0 works5.4.4 Core componentsThe media-consistent electronic exchange of data, also across various fields, calls forgeneral, standardized data models, for example, when personal data is to be exchangedbetween citizen registration and vehicle registration services. The United Nations Centrefor Trade Facilitation and Electronic Business (UN/CEFACT) developed the CoreComponents concept precisely for this purpose. Within the scope of the Deutschland-Online "Standardization" project, a series of core components were created and presentedto the Co-operation Committee for Automatic Data Processing for the Federal-government,Federal-state Government and Municipal Administration Sector (KoopA ADV) for itsapproval and were subsequently made available to Germanys administration. These corecomponents include, among others:a. Natural personb. Name of a natural personc. Organizationd. Authoritye. Addressf. Genderg. Religionh. Marital statusi. ID document
  • 63. 64 SAGA 4.0j. Languagek. Countryl. Time periodDevelopers of data models can use these core components as templates and, by omittingattributes, can restrict value ranges and/or quantities in order to create a specificcomponent which meets the requirements of the respective data interchange. Redundant-free modelling (information cannot be stored in different elements) and cleardocumentation of the core components help to ensure that data can be exchanged withouthuman intervention. The core component "address", for instance, ensures that the housenumber 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 allcommunication partners model their data according to the same rules.The involvement of the XÖV projects in the development of core components ensures thatthey fulfil these requirements. The DOL "Standardisierung" [Standardization] projectensures that new requirements are considered when core components are updated andthat additional core components are created according to demand.Final versions and drafts of core components and specific components are to be stored infuture in the so-called XRepository and are to be made generally available.
  • 64. SAGA 4.0 656 Computational viewpoint: Reference software architectureThe computational viewpoint according to RM-ODP146 describes the architectural structureof distributed eGovernment applications in abstract form and omits implementationdetails. In this chapter, issues of architecture are explained and the resultant referencesoftware architecture is presented. This chapter also offers assistance for designing anddeveloping long-term eGovernment applications for the federal administration which aresuitable for operation, maintenance and further development.The term "Reference Software Architecture" refers to an ideal architecture type of thefederal administration. It describes the design layout of eGovernment applications(specifically: services147 and systems148) of an administration or – more generally – of anorganization.Section 6.1 describes the general, non-functional requirements for developing applicationswhich must be viewed independent of use in eGovernment. The extent of theserequirements influences the architecture decisions to be made.Section 6.2 "Implementation options and architecture paradigms" presents the mainalternatives and guidelines for architecture decisions. The options and paradigms reflectthe current state of the art in software architecture.Finally, a reference software architecture for eGovernment applications is developed insection 6.3 based on the requirements and alternative solutions contained in sections 6.1and 6.2.6.1 General requirements for software applicationsThe computational viewpoint in SAGA provides assistance when developing eGovernmentapplications with a view to the aims identified in SAGA149 and to the guidelines andrequirements presented within the scope of the examination of the enterprise viewpoint inchapter 4.In addition to the specific functional requirements for developing an eGovernmentapplication, which can be derived, for instance, from the technical specification, there is aseries of general requirements which are relevant for the architecture. The following list ofsuch non-functional requirements is arranged alphabetically and does not reflect any146 Refer to chapter 3 "Architecture model for eGovernment applications”, section 3.4 "Computational viewpoint” on page 34147 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
  • 65. 66 SAGA 4.0weighting of the individual requirements with a view to software and technical aspects150.However, the aims of interoperability and reusability laid down in SAGA have anoutstanding role to play.a. Extendibility Extendibility refers to the economically reasonable ability to add new functionalities to the system, or to extend the existing functionality without any adverse effects on such functionality. Especially if eGovernment applications are operated over a long period of time, it must be possible to extend them as laws change.b. Flexibility "Flexibility" generally refers to the ability to modify an architecture in order to meet with new, non-functional requirements in a cost-efficient manner. A topology that can be changed permits quick modification of a distributed architecture and hence improves non-functional requirements, such as availability, reliability and scalability.c. Interoperability Interoperability refers to the media-consistent implementation of transaction services between special inter-agency applications. One organizational precondition for this is that the administration processes must be harmonized so that the eGovernment applications implemented can interact with each other.d. Openness The "openness" feature of an eGovernment system is one of the crucial factors for its successful use. In order to allow existing and new systems to be easily integrated into other systems, such systems must have clearly defined and documented interfaces or must be so encapsulated that they can be at least integrated via portals.e. Performance The "performance" feature of a system generally refers to the ability to execute functionality quickly enough to warrant the usability of the system. A measure for performance is the capacity of a system, i.e. the ability to process a defined number of jobs per time unit.f. Security Security describes the assurance that information can only be modified or published in compliance with the proclaimed security policy. Confidentiality, authenticity and traceability, as well compliance with the Federal Data Protection Act and the relevant chapters on security in the eGovernment manual must be ensured in the use of online services, refer also to chapter 8.1 "IT security concept" on page 91.g. Scalability Scalability refers to the ability to warrant the desired operating efficiency and scalability even as the degree to which an application is used grows. It must be possible to easily distribute the application or its components.h. Availability Availability is a measure that shows how reliably an application makes functionalities, services or resources available.150 Refer to [KBSt 2007]
  • 66. SAGA 4.0 67i. Updating capability eGovernment applications suitable for updating feature economically efficient operation and updating. Efficient updating must be possible for external technicians who were not involved in the development of the application without requiring extensive familiarization or training.j. Reusability Reusability refers to the repeated use of an application or its components with the same or similar services. This avoids redundant development. Reuse is possible on several different levels of abstraction, e.g. exchange of experience between agencies and the use of joint data and process models, architecture patterns and central services.The concrete weighting of the different requirements depends on factors which must beidentified and evaluated when developing the concept for the individual eGovernmentapplications. 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 havepriority in the case of approval and licensing procedures.Additional information can be found in the federal administrations "IT-Architekturkonzept für die Bundesverwaltung" [IT architecture concept for the federaladministration] [KBSt 2007].6.2 Implementation options and architecture paradigmsThe following sections discuss the implementation options and architecture paradigmswhich should be observed when implementing eGovernment applications or which shouldbe used to select suitable options. The options and paradigms reflect the current state of theart. Additional information can be found in the federal administrations "IT-Architekturkonzept für die Bundesverwaltung" [IT architecture concept for the federaladministration] [KBSt 2007]. 6.2.1 Component-based developmentA component is understood to be a software entity which can be used without the need formodification in software applications which are beyond the control of the componentdeveloper. 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 developersof the component.Components offer their functionalities via export interfaces and, if necessary, can use thefunctionalities offered by other components in order to implement the functionalitiesoffered; 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 isindependent of the actual implementation, implementations may be exchanged withoutthe user realizing this and this offers many possibilities for the further development of theimplementation.
  • 67. 68 SAGA 4.0 Component platform Component 1 Component 2 Export interface Export interface Body Body Import interface Import interface Figure 6-1: Component-based developmentAnother major improvement compared to purely object-orientated concepts is offered bystandardized runtime environments for components in the form of application servers orlight-weight frameworks which enable the declarative use of special, independent services,such as authorization, localization, persistence or transaction management forcomponents. Since these functionalities no longer have to be implemented in thecomponents, software creation is both easier and faster. Furthermore, the exchange andsimple reuse of components is possible as contemplated in the paradigm for separatingconcerns in other application contexts. In order for components to be able to use thefunctionality 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 whichstands for the repeated execution of business activities. The approach described belowrequires 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 aService Oriented Architecture (SOA). The individual levels in the illustration are merely usedto show the logic breakdown and do not represent any tiers in the sense of a tier model.
  • 68. SAGA 4.0 69 Service use User Business processes composed of activities Service interface atomar and composed Components for implementing services Service 1 Service 2 OFA service component component component Service delivery Operating infrastructure and data management Legacy ERP DBMS system system Figure 6-2: SOA reference modelServices make their functionalities available via interfaces (dark circles with a bright borderin the middle of Fig. 6-2). How the functionality is performed is irrelevant for the user. Thefunctionality of newly implemented services is carried out by components. Usingconnectors, the functionality of existing systems is subjected to modular encapsulation andmade available as a service.Users (bright circles with a dark border in the upper section of the Fig. 6-2) use the serviceseither directly or integrate these into their business processes. These processes (whiteborder) result from the composition of individual activities (circles). The activities use otheractivities within a composition. Each activity requires either manual access (light circle) andor 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 borderaround two service interfaces). The composition of existing services offers a higher valueservice for the business processes and users.The technical strength of a service oriented architecture is that it makes it possible tocombine existing functionalities irrespective of the technologies used to implement thesefunctionalities. A service oriented architecture, however, must meet with certainpreconditions:a. For interaction between services and their users (the arrows in Fig. 6-2 in the direction of service interfaces and their compositions), a communication basis must be defined which is rooted in generally accepted standards151. The service must master these standards, so that it can be used.151 Refer to section 8.7.1.2 "Middleware communication with applications outside the administration” on page 123
  • 69. 70 SAGA 4.0b. 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 ofdeveloping and operating applications if a larger number of services are made availableand are used by many applications. This then reduces the time and work involved indeveloping new applications because only the functionality which is not yet covered byexisting services now has to be implemented. The central operation of services, inparticular, helps to reduce costs thanks to a more economic use of resources and lowermanpower demand.A directory of electronic services for the public administration is being implemented by theDeutsche Verwaltungsdiensteverzeichnis (DVDV) [German Directory of AdministrativeServices]. This is where the connection parameters of the services, which are required foruse, 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 logicThe separation of business and data storage logic minimizes the dependency of systems orservices on database manufacturers. In response to growing requirements, e.g. concerningperformance or availability, the database can be exchanged without having to change thebusiness logic. In addition to this, the same software can be reused with other databaseproducts with few difficulties.Separation of presentation and business logicSeparating the presentation and business logic offers a technical solution with optimumsupport for multiple presentation channels, such as different browser types or mobiledevices, e.g. personal digital assistants (PDAs). Besides this aspect, the separation ofpresentation 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 toseveral servers – where one server is responsible for the presentation tier and a secondserver for the business logic – and it is from here that the services are triggered which inturn can run on other servers. This has a positive impact on operation with regard tosecurity, upgrading capability and scalability. Special attention should be paid here tocommunication because a less-than-optimum distribution adversely affects performance.Separating client and presentation logicIn order to avoid having to install a separate client software for each application, uniformaccess 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
  • 70. SAGA 4.0 71applications remain usable even if all active contents have been deactivated at the clientend, the data must be processed at the server end in a separate presentation tier. Differentpresentations can be generated for different clients on the basis of the respectiverequirements.Multi-tier architectureThe separation of client, presentation logic, business logic and data storage logic leads to amulti-tier architecture: Client Presentation Communication Security Middle tier Integration components Persistence / Backend Figure 6-3: Structural view - multi-layer architecturea. The client tier is where users and software interact. The data processed by the presentation logic as well as the user interface is visualized. The client tier hence represents different access channels reflecting different users, devices, transmission paths, as well as different application purposes in order to interact with special applications. SAGA refers to the following terminal devices: i. Web access via web browsers or special browser plug-ins ii. Mobile phones and personal digital assistants (PDAs) iii. External applications (e.g. ERP systems)b. The presentation tier implements the processing of application data for the client (e.g. as a website) and the interaction between the user and the special application. The presentation tier includes all the standards for communication with the relevant terminal devices of the client tier.c. The middle tier, also referred to as the business tier, implements the business logic irrespective of its presentation and processes the data from the persistence tier. This is carried out on the basis of services and by components when services are unable to perform this. This is where the program sequence is controlled and this steers interaction between the services and components.d. The persistence tier is responsible for the storage of data objects. It abstracts from the database. The backend is the collective term for functionalities of the operating system,
  • 71. 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 applicationsInteroperability, reusability, economic efficiency, openness and scalability are the keyrequirements for eGovernment applications152. The reference software architecturedescribed is based on implementation options and architecture paradigms from section 6.2which, in turn, are used to fulfil the general requirements contained in section 6.1. Thisarchitecture is based on multi-tier architectures and permits both the use of services as wellas 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 makesense to define a reference software architecture based on just one architecture paradigmto be used for all applications. Instead, the approach which is most suitable must be soughtfor from case to case.The possibility of a service-orientated approach154 should always be examined because thispermits a high degree of flexibility, interoperability, reusability and openness. If anorganization introduces a service oriented architecture, this usually requires close co-operation between IT and technical staff in order to document existing business processesand to identify suitable services. The advantages of the new approach then becomeparticularly obvious when existing processes are revised with a view to the newarchitecture.Compared to component-based architectures, service oriented architectures require anadditional abstraction level. This abstraction is achieved with communication protocolswhich are supported by all component platforms. These protocols then usually have arestricted functionality and are less performant than special platform-specificcommunication platforms. Under the following circumstances, it is advisable to implementa 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 foundin sections 3.4 "Architekturentscheidungen" [Architecture decisions] and 4 "FallbezogeneArchitekturentscheidungen" [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
  • 72. SAGA 4.0 73Architekturkonzept für die Bundesverwaltung" [IT architecture concept for the federaladministration] [KBSt 2007].6.3.2 Introduction of a service oriented architectureThe following section addresses the organizational challenges and the aspect of costs forthe introduction of a service oriented architecture.The main organizational challengesa. 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
  • 73. 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 thebeginning, because the use of new principles and technology means that training will berequired for staff and the previously mentioned organizational challenges must beovercome.6.3.3 Three-tier architecture for servicesWhen implementing a service with a multi-tier architecture according to section 6.2.3, thepresentation tier is omitted, refer to Fig. 6-4. The reason for this is that the services performtheir functionality from within the business logic, i.e. the middle tier. The user of the serviceis 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. Client Service user Communication protocol Service Services interface platform Middle tier Service components Components platform Integration components Persistence / Backend Legacy system ERP system DBMS Figure 6-4: Model of a three-layer architecture of services155 Refer to section 7.1 "IT Service Management with the ITIL" on page 79
  • 74. SAGA 4.0 756.3.4 Four-tier architecture for eGovernment systemsFig. 6-5 provides an example layout with a concrete structure for a multi-tier architecture ofan eGovernment system based on the general description in section 6.2.3. It can be seenthat the presentation tier consists of a Presentation Application Server which generates, forinstance, HTML and XML data with Java Server Pages. The Business Application Server onthe middle tier forms the backbone of the application and performs the specialfunctionalities on the basis of services and components. Via application interfaces (or alsoservice interfaces as shown in Fig. 6-4), external applications and services can access theeGovernment system whilst bypassing the presentation tier. Client Mobile device Web browser Presentation HTML / XML Servlets Java Server Pages Presentation Application Server SOAP Middle tier Application Application component interface JMS J2EE RMI Business Application Server Integration components Persistence / Backend Legacy ERP system DBMS system Figure 6-5: Example model of a four-layer architecture of eGovernment systemsLegacy and ERP systems are integrated via the respective integration components. Thesystems provide their functionalities via application interfaces or service interfaces.Connectors may be needed in order to achieve modular encapsulation of the legacysystems.6.3.5 SecurityIn order to implement the requirements for security, the design recommendationscontained in the E-Government-Handuch [eGovernment manual] must be considered. The
  • 75. 76 SAGA 4.0"Sichere Integration von E-Government-Anwendungen - SIGA"156 [Secure Integration ofeGovernment Applications] and "Sichere Architekturen für Client-Server-Architekturen fürE-Government" [Secure architectures for client-server architectures for eGovernment]modules in the sub-chapter on "IT und IT-Sicherheit" [IT and IT security] are particularlyrelevant. Although designed for component-based implementation, the architectureprinciples 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 todetermine which services and systems have to be newly developed and which existingservices 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 whichstands for the repeated execution of business activities. The OFA services make theirfunctionality available via interfaces. The properties of the implementation are fullyabstracted.Examples of OFA servicesa. Payment platform (ePayment)b. Directory servicec. GeoDataCentre (GDZ)An OFA system is a uniform whole, a software entity, that makes a complex functionalityavailable. 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 eGovernmentapplications, they nevertheless have a key role to play in electronic communicationsbetween 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 specificissues 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
  • 76. SAGA 4.0 77a. ArchiSafeb. Online-Beratung (online consultation)If the data security OFA system158 is used, a separate client application (the OSCI clientenabler) must be installed at the end of the users of the online service. However, the browserremains the client of choice for eGovernment applications which is why this scenario is notpart of the reference software architecture. Client Mobile device Web browser Presentation Presentation Middle tier Middle tier Application interface Service interface Persistence / External application Backend Integration components OFA system Persistence / Backend Middle tier Service interface ERP system Persistence / Specific application Backend OFA service Infrastructure Legacy system ERP system Figure 6-6: Integration of OFA offersMore complex eGovernment applications come with integration components so thatexisting IT applications, such as OFA offers, legacy systems and especially non-SAGAcompliant applications, can be integrated. These integration components – as shown in Fig.6-6 – are directly located in the middle tier. They offer communication possibilities withapplications, such as ERP solutions, in as far as these applications are not available as a158 Refer to the data security OFA system ("virtual post office") http://www.kbst.bund.de/efa-vps
  • 77. 78 SAGA 4.0service and can be triggered via a service interface. In the latter case, no special integrationcomponents are required.
  • 78. SAGA 4.0 797 Engineering viewpoint: IT service management and reference infrastructureThis chapter describes operating processes and the establishment of an effective and secureinfrastructure as the Engineering Viewpoint according to RM-ODP159. Todays dataprotection, data security, efficiency and availability requirements for eGovernment aresetting high standards for operators of applications and technical infrastructures. This iswhy a suitable technical infrastructure has to be set up for the applications from thephysical resources and suitably connected for users through the network level to theexternal services which can only be successfully and securely operated within the scope ofongoing 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 fordesigning, 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 touse a tried-and-tested approach as a basis and to be able to refer to German literature, ITILversion 2.0, which is supported by KBSt documents, is presented in the engineeringviewpoint.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 ITprocesses. IT service management is broken down into the following processes:a. tactical processes for planning and implementing service requests (service delivery), as well asb. 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 ITsecurity which is also implemented as a continuous process160.Successful IT service management requires interaction between the individual processeswhilst mutual control also takes place. ITIL describes in this context the tasks of theprocesses, however, the specific demarcation can be chosen according to the specificcircumstances. Since the processes must be continuously operated, this requires concreteresponsibilities. According to ITIL, this means that roles must first be defined for therespective process managers which must then be filled by individuals. An individual can159 Refer to chapter 3 "Architecture model for eGovernment applications", section 3.5 "Engineering viewpoint" on page 34160 Refer to [BSI 2005]
  • 79. 80 SAGA 4.0assume several roles in this context as long as this does not result in a conflict of interest andrepresentation is secured. This means that when ITIL is introduced, the coordination ofprocesses and responsibilities must begin. SERVICE DESK SERVICE DELIVERY SERVICE SUPPORT Service Level Management Incident Management Availability Management Problem Management IT Service Continuity Configuration Management Management Capacity Management Change Management Finance Management Release Management Figure 7-1:Overview of ITIL processesThe ITIL processes communicate with each other via commonly used informationcollections. The control of the processes depends heavily on reporting which is integratedinto all ITIL processes in order to assure quality. Object success control is also supported byITIL 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 beplanned and lastingly implemented. For this purpose, ITIL calls for the operation of theService Delivery processes.Service Level ManagementWhen developing a new eGovernment application, the service provider and the customernegotiate customer requirements as a concrete service offer in a service agreement (ServiceLevel Agreement, SLA). This is where functionalities, as well as non-functionalrequirements, such as performance (according to the number of users active at the sametime) or availability (with maximum downtimes and recovery times), are co-ordinated. Theaim is to draw up a clear definition of the expectations of both sides regarding a new
  • 80. SAGA 4.0 81service. In addition to the first-time creation of an SLA, subsequent customer requests andthe monitoring of compliance with the SLA are also handled by the Service LevelManagement process. This process steers and monitors both the performance and thequality of a service.Availability ManagementAvailability Management steers the functional provision of eGovernment applicationsduring the required working hours. The aim is to achieve cost-efficient control ofuninterrupted availability in line with business requirements. Dependencies on externalservice 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 ITService Continuity Management (ITSCM) even under the impact of disasters in the ITILprocess. 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 requiredminimum production capacities.Capacity ManagementThe economic use of IT resources should be controlled on a long-term basis for competitiveservices using the ITIL Capacity Management process.Financial ManagementControlling costs for eGovernment applications and hence planning and controllingeconomic efficiency, e.g. in a budget process, are carried out by the ITIL FinancialManagement 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 withthe operative side. The IT services are performed on a day-to-day basis by the ITIL ServiceSupport processes.Service DeskEffective communication with customers is an efficient precondition for the successfuloperation of eGovernment applications. This means that customers or users must beprovided with quick and simple contact to IT. According to ITIL, this means that a centralpoint of contact, the Service Desk, must be set up in order to bundle communicationseconomically whilst providing ongoing user support. In the case of eGovernmentapplications, communication with citizens can also take place via the Service Desk. In orderto boost acceptance, it should be possible to reach a service desk through a number ofdifferent communication paths, such as telephone, email, or web applications.
  • 81. 82 SAGA 4.0Incident ManagementReports of incidents, as well as general queries, must be collected and promptly handled.The ITIL Incident Management process receives reports from users, responds by ensuringconsistent handling with the least possible annoyance for the user, and informs the user ofthe status of trouble-shooting activities. In order to ensure a high degree of satisfactionamong 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 byway of escalation. Incident management should be supported by software, such as aticketing system (also referred to as a trouble ticket system), in order to be able to managemessages and communicate these to other processes and also in order to evaluate them.Incident management also includes reports on security incidents and is hence ofconsiderable importance for information security161.Problem ManagementIf 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. Atthe same time, however, Incident Management commissions the ITIL ProblemManagement 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 efficiencyof IT services.Configuration ManagementThe operation of eGovernment applications requires an information basis for all IT servicemanagement processes. The ITIL Configuration Management process managesinformation concerning the properties and relationships of all components of the ITinfrastructure. This also includes archiving master copies of the software used. The otherITIL processes can use this information or can also report changes in configuration.Change ManagementApplications, infrastructure, documentation, processes and methods must be modified andamended in order to further develop IT or eliminate the causes of incidents. The ITILChange Management process is used to steer and control these changes. One key aspecthere is agreement among all those involved about the expected effects of the plannedchanges in a so-called change-release committee (Change Advisory Board, CAB). Release bythe CAB is a prerequisite for reducing, to a reasonable level, the risk of endangering theavailability of IT services as a result of change conflicts. Changes must be tested and securedthrough suitable fall-back procedures. A regularly updated change calendar simplifiescoordination.Release ManagementInfrastructures are further developed in new releases. The ITIL Release Managementprocess covers the planning, design, generation, configuration, testing, acceptance and161 Refer to [BSI 2005]
  • 82. SAGA 4.0 83putting 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 releaseand, in order to secure ongoing operations, taken into production (roll-out) under thecontrol of Change Management. Release Management is linked to IT procurement and tocontract managements as described in the KBSt publication series (e.g. "ITIL and ITprocurement"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 afar-reaching linking of the Security Management process with the IT Service Managementprocesses. Furthermore, with a view to security management, ITIL also refers the BS 7799163standard by the British Standard Institution; their recommendations are considered as theinternational standard ISO/IEC 279001 in the BSIs IT-Grundschutz [IT Baseline Protection] inBSI-Standard 100-1.Generally speaking, the recommendations by the German Federal Office for InformationSecurity (BSI) on the security of eGovernment applications164 and the BSIs IT-Grundschutz[IT Baseline Protection] (former IT-Grundschutzhandbuch [IT Baseline ProtectionManual])165 must be taken into consideration here. When planning eGovernmentapplications, IT security must be included from the very beginning166. In the interest ofeconomic efficiency, IT security measures must be reasonable. A protection requirementreport, like the one recommended in BSI-Standard 100-2167 should be drafted as early aspossible in order to serve as a basis. Such a protection requirement report classifies the ITinfrastructure on the basis of possible damage in the protection requirement categories ofnormal, high and very high.When a normal protection requirement for eGovernment applications is found, thestandard measures recommend in the IT-Grundschutzkataloge [IT Baseline Protectioncatalogues] can be used. In the case of high or very high protection requirements, a riskanalysis based on BSI-Standard 100-3168 should be additionally carried out with the supportof the IT-Grundschutzkataloge [IT Baseline Protection catalogues]. This can be used not justto evaluate the extensively described risks but also to adopt extended measures from the IT-Grundschutzkataloge [IT Baseline Protection catalogues] or additional measures from theE-Government-Handuch169 [eGovernment manual] in order to compensate for higher risks.The work involved in operating a secure infrastructure may not be economically feasiblefor smaller public agencies so that it could make sense to outsource this to the computercentres 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/
  • 83. 84 SAGA 4.07.2 Design of an eGovernment infrastructureThe purpose of introducing a reference infrastructure in SAGA is to define theinfrastructural preconditions necessary for operating eGovernment applications and therequired system structure. The following goals are to be achieved in line with the protectionrequirements by defining parameters for a reference infrastructure in the sense of anoperating environment.a. Suitable physical protection of systemsb. Suitable availability of systemsc. Suitable security of systems and their componentsd. Classification of systems and their components according to separate security zones Users / External services External Central specific External OFACentral application specific offeringOFA User application offering User Network Internet IVBV Extranet, VPN Network access Access Infrastructure control Access Information & service zone control Management zone Access control Data backup Access control Logic & processing zone Access control Access control Data zone External backup Figure 7-2: Engineering viewpoint of an eGovernment application
  • 84. SAGA 4.0 85e. Scalability of systems and infrastructuresf. Simple service, efficient maintenance and updating of complex systems and their components by operating personnelFig. 7-2 on page 84 shows a general overall view of a distributed eGovernment applicationwith the user, network and infrastructure areas.Both the network and the user areas are typically beyond the control of the operator of aneGovernment 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 asuitable system structure in order to meet the operational requirements for eGovernmentapplications.The requirements for a computer centre and its IT infrastructure will be described in thefollowing sections.7.2.1 Physical infrastructureServers and IT systems must be installed in suitable locations if they are to be protectedagainst force majeure, such as lightning, fire, water, excessively high temperatures, ortechnical failure, such as power outages, as well as organizational shortcomings, such asunauthorized access to protected rooms. This is why computer centres planning to operateeGovernment applications should use the protection requirement report in order toimplement the required IT security measures according to the BSIs IT-Grundschutzkataloge [IT baseline protection catalogues]. These measures include, forinstance:a. Installing IT systems in suitable roomsb. Controlling access to these roomsc. Suitable fire detection and fire-fighting systemsd. Suitable power supply systemse. Suitable air-conditioning systemsf. Data backup according to the related data backup concept7.2.2 Zone concept and communication relationsThe systems inside the computer centre are located in different zones which are defined onthe basis of the relevant safety and security requirements for the services and data of therespective zones. In order to ensure that the zone concept covers the general protectionrequirements of eGovernment applications, at least the four zones described below shouldbe implemented within a computer centres infrastructure. Operation of complexeGovernment applications may require additional zones. These zones should be adequatelyseparated 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
  • 85. 86 SAGA 4.0a. 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 zoneThe information and services zone covers that part of the network which is located betweenthe Internet and the other zones of the network. This zone contains servers which can beaccessed by external networks or which, for their part, use the services of externalnetworks. Further information zones should be set up if systems with different securitylevels are to be operated.In line with protection requirements, communications between the systems of theinformation and services zone and the systems of the logic and processing zone should beprotected by encrypted communication channels.Logic and processing zoneThe systems of this zone process data from the data zone and make such data available tousers via systems of the information and services zone. Direct communication betweenexternal networks – such as the Internet – and the logic and processing zone is notpermitted.Data zoneThe data zone contains all the systems where data is stored and made available for longerperiods of time. Access to this zone is permitted from the processing zone and themanagement zone only. Direct access from external networks is not permitted under anycircumstances. In the same way, direct access from this zone to other zones is not permitted.One exception to this is the management zone.Management zoneThe management zone contains all the systems which are needed for administrativepurposes or for monitoring systems in other zones. Furthermore, this zone can also containcentral user administration or authentication services. Access from the management zoneto other zones and vice versa is hence permitted.Access from within external networks to the management zone is not permitted under anycircumstances.
  • 86. SAGA 4.0 87Data backupEvery zone should include its own data backup components. Data of the information zonesshould 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 computercentre as well as access by and to external networks. Different technologies can be used forthese purposes.The interface between the information and services zone and external networks is the mostsecurity-critical point and is hence protected by a combination of multiple securitymechanisms. Different network segments and address areas are separated here on thenetwork protocol level. Internal network addresses are masked and are hence notpublished in external networks. In the case of small networks on an IPv4 basis without ahigh 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 externalnetworks is restricted to defined services in the information and services zone. The filterrules are typically implemented on firewalls or firewall routers which screen theinformation in the headers of the incoming data packages on the basis of package filtersand 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 securitygateways. In order to adequately control access to the sensitive areas of the logic andprocessing zone as well as the data zone, firewalls should be used because of theircomprehensive filter options. These firewalls work on the basis of dynamic package filters(stateful inspection) and are capable of monitoring not just individual packages but evencommunication streams involving multiple packages. Dynamic package filters enable thevalidation of network connections not just on the basis of invariable rules, but additionallyeven on the basis of historical communication relations.Thanks to simple and flexible administration, VLAN technology is the system of choice forcontrolling access to the systems in the management zone. For this purpose, all the systemsrequiring access to a service in the management zone are combined to form a virtualnetwork segment (VLAN). In order to prevent unwanted communication between theindividual zones via the VLANs of the management zone, all the systems are fitted with asecond network interface which may not be used for any purposes other thanadministration and which is fitted with a package filter.Using VLAN technology for connecting any zones other than the management zone is notrecommended for security reasons.
  • 87. 88 SAGA 4.07.3 Networks as the link between an infrastructure and external services and usersThe network level is the link between the systems of the computer centre infrastructure andexternal 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), theInformationsverbund der Bundesverwaltung (IVBV) [Federal Administration InformationNetwork], 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 thenetwork level. Although a clear consolidation trend has been observed in recent years inthe field of network technologies, many different technologies are still in use. However,abstraction to higher protocol or application levels can render the system interoperable, sothat 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 orextranets has an important role to play in order to ensure reliable access to users andexternal services. When eGovernment applications are designed, the necessarybandwidths must hence be made available on the basis of an assessment of the anticipatednetwork communication, and the access control mechanisms described in section 7.2.3must be implemented.7.4 Access to external servicesExternal services use the infrastructure of eGovernment applications via networks, refer toFig. 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 ofAdministrative Services] forms a universal infrastructure for eGovernment in Germany. Thisis where the addressing parameters of the public administrations online services are storedin XML format. These are primarily technical descriptions of the services in WSDL format172as well as supplementary URLs and cryptographic certificates. The DVDV makes it possibleto find all the information required for automated machine-to-machine communication inmachine-readable form. This is the basis for fully automated online services betweenmachines 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
  • 88. SAGA 4.0 89The LDAP173 directory service standard is the technical basis for this and defines thestructure for the storage and retrieval of DVDV information. The core of the DVDV is thecentral 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 wherewrite 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 datastock on distributed (e.g. in the federal states) DVDV federal-state servers which share thequery load for the individual data retrievals. OSCI transport protects the updating andreplication of the WSDL files and the supplementary parameters. DVDV DVDV federal update client master (per fed. state) TESTA network DVDV DVDV- DVDV fed. state fed. state fed. state server 1 server 2 server n Other networks / Internet Clearing Clearing house A house B Agency network / infrastructure Agency 1 Agency 2 Agency 3 Agency 4 Agency 5 procedure procedure procedure procedure procedure Figure 7-3: Structure of the German Directory of Administrative ServicesThe first application since 1 January 2007 is the implementation of the Framework Act onRegistration, which was revised in 2002, especially the part concerning data transmissionsbetween federal states. This makes paper-based responses and updating of the civil registerobsolete. Instead, the exchange of data between participating public agencies is exclusivelyelectronic and automated. Other services already integrated (as per mid-2007) are theservices of the Federal Central Tax Office for communication with the registrationauthorities within the scope of issuing uniform tax ID numbers and the municipal coreidentity register of the Free State of Saxony. The architecture of the DVDV is designed insuch a manner that any automated communication relationships in eGovernment canbasically use its services.173 Lightweight Directory Access Protocol, refer to section 8.8.1 “Directory services and registries“ on page 130; the open source reference implementation OpenLDAP is used for DVDV, refer to http://www.openldap.org
  • 89. 90 SAGA 4.0BIT operates the coordination office of the DVDV. This secures the flow of information tousers 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 administrations one-for-all offers (OFA offers)174 – brokendown into OFA services, OFA systems, OFA concepts and infrastructures – offers that can beused by public agencies to integrate their eGovernment applications are made available viathe Internet and via the IVBV.Services, such as the ePayment OFA service175, can be accessed via the web service interfaceson the Internet. For this purpose, the OFA service provides the web service interfacesrequired at the server end along with a reference implementation for accessing the webservices by the relevant eGovernment application. Communication with external specialapplications 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 andthe form management system177, are implemented within the computer centreinfrastructure 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
  • 90. SAGA 4.0 918 Technology viewpoint: Standards for IT architecture and data securityIn this chapter, technical standards are assigned to the individual elements of thearchitecture model introduced in chapter 3. Furthermore, this chapter also provides briefdescriptions of these technical standards. If no version numbers of standards are stated, theversion which is most stable from a market point of view should be used, even though this isnot 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 achieveand maintain a suitable level of IT security. For this purpose, an IT security concept will bedrafted and further-developed in an IT security management process which will becontinuously operated following its initiation. Since December 2005, the Germany FederalOffice for Information Security (BSI) has recommended and supported an approach inseveral BSI-Standards and the IT-Grundschutzkataloge [IT baseline catalogues] which waspreviously presented in the IT-Grundschutzhandbuch (IT-GSHB) [IT Baseline ProtectionManual].8.1.1 Management systems for information securityThe first step towards a comprehensive IT security concept requires the creation of amanagement 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 securitymanagement system) should be applied within the scope of the security concept. Thestandard is fully compatible with ISO standard 27001 and also considers therecommendations 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 securitymeasures must be adopted for the IT application and the data to be processed which are178 Refer to http://www.bsi.de/literat/bsi_standard/standard_1001.pdf179 Refer to http://www.iso.org/
  • 91. 92 SAGA 4.0suitable for the protection requirement identified. The system approach for the IT conceptinvolves 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 baselineprotection approach]. The standard describes how IT security management can be set up inpractice and operated. It should be used within the scope of the IT security concept. Withthis approach, IT security concepts can be created, simply and efficiently, whilst IT securitycan be maintained and improved in ongoing operations.8.1.2.1 Protection aimsProtection 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 categoriesThe protection requirements must be identified for each IT application of the dataprocessed. These requirements are a function of the potential damage that can be causedby impairment of the IT application in question with regard to the protection aims definedin section 8.1.2.1.A protection requirement category can be assigned to every protection aim in order toevaluate applications from a security point of view. In "BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise" [BSI standard 100-2: IT baselines protection approach], the followingclassification is hence made:180 Refer to http://www.bsi.de/literat/bsi_standard/standard_1002.pdf
  • 92. 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 categoriesOne particular aspect which must be considered when determining protectionrequirements is whether personal data is processed in order to ensure that data protectionlaws 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 protectioninformation 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 analysisshould be applied to areas with security requirements that go a long way beyond what isnormally required. The reasons for a risk analysis could be a high or very high securityrequirement, the use of applications or components not (yet) addressed in the IT BaselineProtection 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 securityconcepts. This specification was the result of the merger of the Industrial SignatureInteroperability 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 usein practical application. The specification focuses on conformance requirements whichmust be fulfilled by compliant PKI components and applications during the generation andprocessing of certain data objects, such as certificates.The ISIS-MTT specification chiefly consists of a kernel document which is exclusively basedon the profiling (restriction of optional characteristics) of international standards andwhich is hence expected to ensure interoperability on an international scale. This core181 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/
  • 93. 94 SAGA 4.0specification is mandatory for all manufacturers and suppliers and can be supplemented byoptional 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 followingcontents:1. Establishing public-key certificates, attribute certificates and certificate revocation lists2. 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 messages4. 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 units5. Validity check for public key certificates and attribute certificates6. Approved algorithms for hash functions, signatures, encryption, authentication of messages to and from the certification authority; approved algorithms for XML Signature and XML Encryption7. Description of the "Cryptographic Token Interface" (PKCS#11) with data types and functions8. Profiling and expanding XML signatures and XML encryption Mandatory: BSI, IT-Grundschutz-Kataloge [IT Baseline Protection Catalogues]The BSIs IT-Grundschutz-Kataloge185 [IT Baseline Protection Catalogues] should be appliedand the standard security measures described there should be implemented. The use ofmodule, measure and risk catalogues supports a component-orientated work approachwith 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 undVerschlüsselung in der Verwaltung [Guideline for the Introduction of the ElectronicSignature and Encryption in the Administration] issued by the KoopA ADV186 is designed tofacilitate solutions to cryptographic problems for selected projects in the publicadministration, and is hence primarily devised as a working aid for public agencies. Typicalproblems and tasks are defined in the form of scenarios for which potential solutions areidentified 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
  • 94. SAGA 4.0 95 Recommended: BSI, E-Government-Handbuch [eGovernment manual]The BSI E-Government-Handbuch187 [eGovernment manual] contains organizational andtechnical recommendations concerning the use of IT in eGovernment applications. Whenit comes to developing an eGovernment application within the meaning of SAGA, thesecurity-related recommendations contained in the manual are particularly relevant188.The chapter on "IT und IT-Sicherheit" [IT and IT security] contains securityrecommendations in the following modules:1. General information on secure eGovernment applications2. Authentication in eGovernment3. Optimization of web content retrieval4. Secure integration of eGovernment applications5. Secure payment methods for eGovernment6. Secure communication in eGovernment7. Secure client-server architectures for eGovernment8. eGovernment without active contentThe recommendations of the E-Government-Handbuch [eGovernment manual] shouldalways 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 ITbaseline security. The E-Government-Handbuch [eGovernment manual] providesrecommendations here for the design and implementation of a corresponding level of ITsecurity.8.2 Process models8.2.1 Technologies for process modelling Mandatory: Role models and flow chartsRole models and flow charts should be used to define simple processes. All the roles andsystems related to a process must be identified, and the process steps must be described inthe form of flow charts. In a broader sense, flow charts should be orientated towards DIN66001: "Informationsverarbeitung, Sinnbilder und ihre Anwendung" [Informationprocessing, 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
  • 95. 96 SAGA 4.0 Mandatory: Unified Modeling Language (UML) v. 2.0The Unified Modeling Language (UML)190 should be used for object-orientated modelling inthe preparation and documentation of large projects. Use cases and activity diagrams are aparticularly 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.xXML 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/IEC19503:2005193 .8.3 Data models8.3.1 Technologies for data modelling Mandatory: Entity Relationship Diagram (ERD)Entity Relationship Diagrams should be used when developing relational databaseschemas. Functional data models for a special rough concept should also be presentedusing ER diagrams. Mandatory: Unified Modeling Language (UML) v. 2.0UML 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 byother tools. XML data structures can be directly generated from the correspondingspecifications.8.3.2 Interchange formats for data models Mandatory: XML Schema Definition (XSD) v1.0XML schemas according to the World Wide Web Consortium (W3C)194 should be generatedusing 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
  • 96. 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, easierto read and yet more expressive.Although XSD is mandatory for the structured description of data, the use of Relax NG is stillpossible because Relax-NG schemas can be transformed to XML schemas using (OpenSource) tools197. Recommended: XML Metadata Interchange (XMI) v2.xAnalogous 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 aboutresources on the web that was developed by W3C. RDF is designed to describe metadataand ontologies and hence forms an important part of Semantic Web. RDF makes it possibleto declare vocabulary, i.e. to define terms, so that the relevant information about resourcesis described in such a manner that it can be gathered, integrated and reused. Simplevocabulary, such as Dublin Core, can also be used in RDF. RDF should be used to describemetadata for web resources. Recommended: Dublin Core (DC)Dublin Core (DCMI Metadata Terms)199 is a widely used standard which was standardized byISO200 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 basedon the ISO 15836-2003 standard from February 2003. This standard should be used for themetadata description of websites, digital objects and documents.The second chapter of the specification ("The Dublin Core Metadata Element Set") containsthe 15 core elements of the standard: contributor, coverage, creator, date, description,format, identifier, language, publisher, relation, rights, source, subject, title and type. Eachelement 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
  • 97. 98 SAGA 4.0elements – called "refinements" or "qualifiers" – are available for certain elements, andenable a more precise description of resources.The elements of Dublin Core can be used in HTML/XHTML and RDF/XML documents. InHTML documents, Dublin-Core metadata can be stated with the META element in thedocument header.8.4 Application architectureThis section defines programming languages and technologies for implementing theapplication architecture. The first part defines standards for the middleware of theeGovernment architecture module with special emphasis on the aspect of applicationintegration. This is followed by an extension of the standards to cover applications withoutmiddleware or with a low middleware share, respectively, so that the middleware standardscan 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 currentversion to a certain extent.Deviations from preferred technologies (i.e. mandatory, recommended technologies) areacceptable 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) v5Technologies of the Java Platform, Enterprise Edition (JavaEE)202 should be used to developand 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, andc. 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 developmentprocess. Java EE in its entirety constitutes an architecture that considers and supports majoraspects of business-critical applications. Java EE already offers important function moduleswhich can be used to develop applications. Since version 1.4204, these also include standardprogramming interfaces (APIs) and technologies as so-called core libraries: JavaAuthentication and Authorization Service (JAAS), Java API for XML Parsing (JAXP) and JavaNaming and Directory Interface (JNDI). All the core libraries should be given preferenceover 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
  • 98. SAGA 4.0 99The difference between Java EE v5205, which was finalized in May 2006, and its predecessorJ2EE v1.4 can be found especially in the upgrading capacity of applications and thesimplification of the programming model. Enhancements were also made, for instance, tothe definition and use of web services and the mapping of Java classes to XML anddatabases.Compared to Java SE v5, Java EE v5 offers the following APIs and technologies as so-calledoptional libraries:a. Java Message Service (JMS) v1.1b. J2EE Connector Architecture (JCA) v1.5c. 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, andi. Java Servlet API v2.5.Thanks to the Java Community Process208, more and more application-near elements willincrease the diversity of Java EE in the near future. New elements are defined via so-calledJava Specification Requests (JSR). Mandatory: Java Platform, Standard Edition (Java SE) v5If an application does not require full Java EE functionality, neither initially nor on apermanent basis, Java EE technologies should be used individually as an alternativesolution. The basis for this is the Java 2 platform as the Standard Edition (Java SE)209. Theindividual technologies should be used in accordance with Java EE specification 5210 inorder 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 theform 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/
  • 99. 100 SAGA 4.0The ECMA-335213 "Common Language Infrastructure (CLI)" standard (ISO/IEC 23271:2006and ISO/IEC TR 23272:2006214) defines an infrastructure for different system environments inwhich applications can be executed which were written in different programminglanguages. The infrastructure abstracts from specific properties of the systemenvironments so that applications do not have to be changed in order to run them ondifferent systems.There are two implementations of the ECMA standard. .NET-Framework from Microsoftruns under Windows only. The two ECMA standards are based on .NET v2.0 and are hencealso part of .NET v3.0. A further implementation, called Mono215, ensures availability forfurther operating systems.The two ECMA standards do not form a complete development framework because they donot support, for instance, the implementation of clients and presentation layers. Under observation: Business Process Execution Language for Web Services (BPEL4WS) v1.1BPEL4WS216 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 languagewhich supplements web services and the related standards (SOAP, WSDL, UDDI) withbusiness transactions.Major infrastructure and application suppliers support the specification. Furthermore,tools, including Open-Source solution217, are provided. BPEL4WS was developed further tothe OASIS standard WS-BPEL 2.0. Under observation: Web Services Business Process Execution Language (WS-BPEL) v2.0WS-BPEL218 v2.0 was adopted by OASIS in April 2007 as the standard. The standard is used tocompose business processed based on web services. Tools for WS-BPEL v2.0 arecommercially 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 isalso available for simple eGovernment applications without middleware. Recommended: PHP Hypertext Preprocessor (PHP) v5.xPHP219 (recursive acronym for "PHP: Hypertext Preprocessor") can be used for applicationswithout an integration requirement, i.e. non-distributed, stand-alone applications which213 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/
  • 100. SAGA 4.0 101do not communicate with one-for-all offers (OFA offers)220 with legacy systems or with othereGovernment special applications. PHP is developed as an open-source project by the PHPGroup and represents a script language embedded in HTML for developing webapplications.Version 5 features comprehensive support for object-orientated programming concepts.Procedures for data encapsulation, referencing of variables and exception handling markimportant 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 bymiddleware. 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 accessto information possible via different media. In Germany, the following media are currentlythe most popular, so that optimum conditions for the widespread use of eGovernmentapplications 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 havenot yet resulted in uniform recommendations. The so-called "thin client" seems to be themost 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 aspossible.8.5.1 Access to information with computersTwo different clients are generally available on computers221 in order to access or receiveinformation: 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, suchas local data volumes. Whenever active contents are used, no client technologies otherthan those permitted in SAGA may be used. The use of Active-X-Controls is generally notpermitted. When active contents are used, a parallel offer without active contents shouldalso 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.
  • 101. 102 SAGA 4.0 Mandatory: Java Network Launching Protocol (JNLP) v1.5Java client applications should be delivered via the Internet using the Java NetworkLaunching Protocol (JNLP)222. In this case, the "Java Web Start"223 reference implementationcan be used.The use of JNLP enables the simple, platform-independent distribution of Java applicationsand avoids version conflicts with Java Runtime Environments (JREs).8.5.1.1 Web browsersIn order to enable wide-spread use of the eGovernment applications on offer, web browsersshould be used as the front-end device and these should be capable of processing andpresenting the presentation-tier formats (refer to section 8.6). The following browser-basedclient technologies are permitted in this context:a. The use of cookies is permitted on condition that i. these are not persistent, and ii. websites of a domain do not include contents of other domains which set cookies. The recommendations for the HTTP protocol according to section 8.7.5 must be taken into consideration in this context.b. The use of Javascript is permitted, however, it must be ensured that the websites can still be used even if Javascript was deactivated. This demand corresponds to BITV224 which is classified as mandatory. This ensures that the user is not forced to lower his/her security settings due to eGovernment applications. Section 8.6.4 "Active contents" on page 108 must be taken into consideration when Javascript is used.c. The use of Java Applets is permitted if these are signed by the server and can hence be identified by the client as authentic and non-corrupted. Manufacturers of Java Applets must subject their products to quality assurance, preferably by an independent software company, or must at least warrant the quality of their products in a declaration of quality.225d. 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://bundesrecht.juris.de/bitv/)225 Further information on this subject can be found on the web at: http://www.kbst.bund.de/saga-applets.
  • 102. SAGA 4.0 103g. The statutory instrument (ordinance) on barrier-freedom remains fully applicable to the use of permitted client technologies.8.5.1.2 Client applicationsThe 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, orif the functionality of a web browser must be reasonably seen to be inadequate, forexample, in the case of complex business transactions with direct file system access or use oflegacy software. These applications are installed on the client computer and must beupdated as required by technical progress. Updates can be made available on CD-ROM or assigned applications for downloading226 from a website. The use of Java applications isrecommended (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 clientThe e-mail clients used to receive, send and process e-mails must at least ensure technicalsupport for the e-mail standards referred to in section 8.7.3 "E-mail communication". Notethat communication of these clients is standardized with regard to communication withpublic administrations only and/or restricted to the above. With regard to the use ofexternal mail servers not connected to federal institutions, the client is not subject to anyrestrictions 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 either226 Refer also to "Java Network Launching Protocol (JNLP) v1.5" on page 102
  • 103. 104 SAGA 4.0a. a small display,b. low bandwidth, orc. no standard keyboardand must support the standards offered by servers for mobile devices of the presentationtier227. Furthermore, the standards, which are generally described for the presentation ofcontents by computers, should also be fulfilled as comprehensively as possible by themobile 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 handledvia a subset of the standards defined for communication and interaction between internalsystems. In this respect, XML via SOAP is considered to be equivalent to RMI with regard toserver-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 ofcommunication 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. useridentification / password, PIN / TAN or certificates. The "Authentisierung imeGovernment"230 [Authentication in eGovernment] module of the E-Government-Handbuch [eGovernment manual] issued by BSI addresses different authenticationmethods with a view to aspects of technical security. Recommended: Security Assertion Markup Language (SAML) v2.0SAML231 is an XML-based format for exchanging authentication information. The exchangeof data in a uniform format especially supports interoperability between eGovernmentapplications. 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 130230 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
  • 104. SAGA 4.0 105 Under observation: Kerberos v5Kerberos232 is a protocol for authentication in computer networks that was developed bythe Massachusetts Institute of Technology (MIT). Interoperability is supported through theuniform exchange of authentication data. However, operating-system dependentexpansions do sometimes lead to incompatibilities between different implementations.8.6 PresentationThe presentation tier provides information to the clients. Depending on the givenapplication, different formats must be made available. These are listed in the followingsections. The use of open interchange formats which offer a sufficient number of functionsand 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 partiesinvolved, even as an alternative - to the mandatory and recommended formats usingformats 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 thiskind of barrier-free presentation, the requirements of the "Verordnung zur Schaffungbarrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz(Barrierefreie Informationstechnik Verordnung – BITV)"233 [Ordinance on the creation ofbarrier-free information technology pursuant to the law on equal opportunities for thedisabled (barrier-free information technology ordinance – BITV)] are to be adhered to. Thisstatutory instrument implements section 11 of the "Behindertengleichstellungsgesetz"[Equal Opportunities for Individuals with Disabilities Act] and, in particular, considers theWeb Content Accessibility Guidelines234 of W3C, version 1.0. Concerning the barrierfreedom 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/
  • 105. 106 SAGA 4.08.6.2 Character sets Mandatory: Unicode v4.x UTF-8In order to provide a sufficient number of characters for the different letters, numbers andsymbols 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-16If documents are written in a non-west European language (e.g. Greek, Bulgarian), ISO10646: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.01HTML is the established language for publishing hypertext on the World Wide Web. Inaddition to the text, multimedia and hyperlink functions of earlier HTML versions, HTMLv4.01239 supports more multimedia options, script languages and improved forms and printfunctions. 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. Theseparation of the document structure and presentation has been improved. In this respect,the use of stylesheets instead of HTML presentation elements and attributes is activelyencouraged. HTML 4 is also making great progress with regard to the internationalizationof documents in an effort to make the World Wide Web truly world-wide. Mandatory: Multipurpose Internet Mail Extensions (MIME) v1.0The Multipurpose Internet Mail Extensions (MIME) format should be used for thestandardized definition of the format of a file or any part thereof. It enables the e-mail clientor the web browser to unambiguously identify the file type, refer to RFC 2045 to RFC2049240. The official list of possible manifestations of MIME types can be found at theInternet 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/
  • 106. SAGA 4.0 107 Mandatory: Java Servlet v2.5Servlet v2.5242 should be used for the dynamic generation of web contents. Servlet v2.5makes it possible for application servers to accept and send a dynamic response to clientqueries on the basis of Java EE 5. Mandatory: Java Server Pages (JSP) v2.1JSP v2.1243 should be used for the dynamic, server-based generation of web contents. JSP v2.1contains an Expression Language (EL) which is used to separate the Java Code from the JSPCode and to embed it in statistical fragments (e.g. HTML). JSP v2.1 is based on Java Servletv2.5 technology. Recommended: Extensible Hypertext Markup Language (XHTML) v1.0XHTML v1.0 Second Edition, a W3C recommendation244 from August 2002, is an exchangeformat (reformulation of HTML v4.0 whilst maintaining conformance to XML) which meetswith a host of requirements concerning interoperability and barrier freedom. The use ofXHTML 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-formedaccording to XML) significantly boost the readability of the source code and hence the costof its maintenance and further development. XHTML 1.0 is supported by all customarybrowsers. 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.0Extensible 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.0If applications use different XML schemas, conversion from one format to another canbecome necessary for data interchanging purposes. This format conversion operationshould be carried out using the XSLT247 language defined by W3C as part of XSL (ExtensibleStylesheet Language).242 Published as JSR-000154 (Maintenance Release), refer to http://www.jcp.org/en/jsr/detail? id=154243 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
  • 107. 108 SAGA 4.0 Under observation: Extensible Stylesheet Language (XSL) v1.1XSL v1.1 has been a W3C recommendation since 5 December 2006248. A number of newfeatures 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, toolsupport and the relevance of the practical application of the standard are not as advanced. Under observation: Extensible Stylesheet Language Transformations (XSLT) v2.0Extensible Stylesheet Language v2.0 was adopted in January 2007 as a W3Crecommendation249. It offers many new features, such as the use of XPath 2.0. Otherenhancements include the output methods, as well as sorting and grouping options.XSLT v2.0 does not come with full downward compatibility. Moreover, few processors areavailable 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, ActiveXControls or flash animations) and which are executed on the client (by the browser or by theoperating system). When active contents are used, the restrictions described in section 8.5must be taken into consideration. Mandatory: ECMAScript Language SpecificationIn 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 datedDecember 1999. This specification was also adopted by ISO/IEC as a standard under thename ISO/IEC 16262251.8.6.5 Forms Under observation: XForms v1.0XForms is a specification252 for web forms. The aim of this specification is to replace theforms implemented in HTML or XHTML. XForms offers a wider range of functions and in thecase 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 XFormsby 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/
  • 108. SAGA 4.0 1098.6.6 Interchange formats for data Mandatory: Extensible Markup Language (XML) v1.0XML 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 andthe 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 databetween all the information systems relevant for administrative purposes.New systems to be installed should be capable of exchanging data using XML. Existingsystems do not necessarily have to be XML-enabled, however, they should aim to be able toexchange XML data using adapters (integration components). Under observation: Election Markup Language (EML) v4.0Standard Election Markup Language (EML)255 can be used especially in order to exchangedata in the environment of eVoting processes.EML v4.0 was adopted in February 2006 as the OASIS standard. This language defines aseries of XML schemas which are suitable and which implement a generic election process.These election processes can include public elections (general elections, municipalelections) or private elections (works council elections, secret ballots). EML can be adaptedto all scenarios and also supplies security functions for data backup. Under observation: Extensible Markup Language (XML) v1.1XML 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 beenimproved and inconsistencies in line end markings have been eliminated. There arecurrently almost no parsers for XML v1.1.8.6.7 Exchange formats for documents8.6.7.1 Formats for text documents for exchanging informationText documents used to exchange information should only be read by the target group andshould 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/
  • 109. 110 SAGA 4.0 Mandatory: Portable Document Format (PDF) v1.4Adobes platform-independent Portable Document Format should be used for textdocuments where no further editing is foreseen and to support forms and barrier-free textdocuments. 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 imE-Government" [Secure Internet Presence] module of the eGovernment manual must beconsidered 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 nolonger be copied / searched for in PDF. Similarly, the PDF password function, irrespective ofthe key strength of encoding, is not a sufficient security measure for documents withcontent that needs to be protected, because this function can be bypassed using theappropriate tools. Mandatory: Hypertext Markup Language (HTML)Hypertext documents used to exchange information, e.g. newsletters, should be used inHTML260 format, refer to section 8.6.3 "Technologies for information processing" on page106. Recommended: Portable Document Format (PDF) v1.5PDF version 1.5261 is the successor to PDF v1.4, which was classified as "Mandatory". For olderversions of Windows and MacOS, there are at times no distributions of Acrobat Reader forPDF 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 andcontent-related tagging. If this format is used, the recommendations of the "SichererInternet-Auftritt im E-Government" [Secure Internet Presence] module of the eGovernmentmanual must be considered with regard to active contents263. Under observation: Portable Document Format (PDF) v1.6PDF version 1.6264 is currently used to a very limited extent only. This version is the successorto 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 theembedding of file attachments. PDF version 1.6 is supported by Acrobat Reader265, version 7and higher. If this format is used, the recommendations of the "Sicherer Internet-Auftritt im257 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
  • 110. SAGA 4.0 111E-Government" [Secure Internet Presence] module of the eGovernment manual must beconsidered with regard to active contents266.8.6.7.2 Formats for text documents for further processingIt must be possible to edit text documents which are foreseen for further processing. Adistinction is made between simple text documents and complex text documentscontaining layout information. Mandatory: TextSimple, mostly non-structure text documents which are foreseen for further processing andwhich 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. Thecharacter sets to be used are laid down in section 8.6.2. Recommended: Open Document Format for Office Applications (OpenDocument) v1.0OpenDocument267 was standardized by OASIS as an XML-based document format for texts,spreadsheets, presentations and other Office documents. The contents of the document areseparate from the information about its layout and can be processed independent of eachother. OpenDocument can be used to exchange complex documents that are foreseen forfurther processing. In November 2006, OpenDocument v1.0 was published as a standardunder the name ISO/IEC 26300:2006268. OpenDocument is supported, for instance, by theplatform-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 Officedocuments, Office Open XML270 was published by ECMA in December 2007 as the ECMA-376standard. It can be used to exchange complex documents which are to be processedfurther.8.6.7.3 Formats for spreadsheets for exchanging informationSpreadsheets used to exchange information should only be read by the target group andshould not be changed. This is why no further editing is foreseen. Mandatory: Portable Document Format (PDF) v1.4Analogous 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
  • 111. 112 SAGA 4.0 Recommended: Portable Document Format (PDF) v1.5Analogous to section 8.6.7.1 on page 109. Under observation: Portable Document Format (PDF) v1.6Analogous to section 8.6.7.1 on page 109.8.6.7.4 Formats for spreadsheets for further processingIt must be possible to edit spreadsheets which are foreseen for further processing. Adistinction is made between simply structured data and complex documents, even withlayout information. Mandatory: Comma Separated Value (CSV)Tables with simple structure data without layout requirements should be exchanged usingComma Separated Values271 (file extension: .csv). Under observation: Open Document Format for Office Applications (OpenDocument) v1.0Refer to section 8.6.7.2 on page 111. OpenDocument272 supports the referencing of formulalanguages, however, these do not form part of the standard. An OASIS Technical Committeeis 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 informationPresentations used to exchange information should only be read by the target group andshould not be changed. This is why no further editing is foreseen. Mandatory: Portable Document Format (PDF) v1.4Analogous 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
  • 112. SAGA 4.0 113 Mandatory: Hypertext Markup Language (HTML)Presentations that cannot be changed which are available in hypertext document formatshould be exchanged in HTML274 format, refer to section 8.6.3 "Technologies forinformation processing" on page 106. Recommended: Portable Document Format (PDF) v1.5Analogous to section 8.6.7.1 on page 109. Under observation: Portable Document Format (PDF) v1.6Analogous to section 8.6.7.1 on page 109. Under observation: Synchronized Multimedia Integration Language (SMIL) v2.0SMIL is an XML-based, standardized language for writing interactive multimediapresentations275. "A typical example of such an application is a multimedia news centrewhich plays audios and videos to a message whilst background information is displayed atthe same time on HTML websites."276There is a host of free SMIL players. Of the browsers currently available on the market, up tonow only the Internet Explorer supports a subset of SMIL277.8.6.7.6 Formats for presentations for further processingIt must be possible to edit presentations which are foreseen for further processing. Under observation: Open Document Format for Office Applications (OpenDocument) v1.0Analogous 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 exchangeThe "communication" interaction stage requires the exchange of secure documents. Thisincludes, for example, securing documents as e-mail attachments as well as securingdocuments 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.pdf277 Refer to http://www.w3.org/AudioVideo/#SMIL
  • 113. 114 SAGA 4.0The ISIS-MTT v1.1 standard is relevant with regard to securing e-mail attachments whilstXML Signature and XML Encryption as XML-specific standards are relevant for the secureexchange of XML documents (e.g. for forms designed for further processing). Mandatory: Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 3ISIS-MTT v1.1 defines an interoperable data interchange format for signed and encrypteddata. It also considers the securing of binary data (in particular, Part 3: Message Formats), sothat secured transmission of all kinds of files as e-mail attachments is possible. Mandatory: XML SignatureThe 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 ofdata (however, usually XML) by providing an XML schema and a set of processing rules (forgenerating and validating the signature). The signature can cover one or more documentsand/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 XMLdocument 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 partscan be edited. For instance, a user can fill in certain parts of a signed XML form withoutviolating the integrity of the document. This was not possible with conventional signaturesbecause the complete document was always signed, so that any change / addition wouldhave meant a violation of its integrity. Mandatory: XML EncryptionThe 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 theencryption/decryption of entire documents, including XML documents, XML elements andcontents of XML elements.Together with XML Signature, XML Encryption is the foundation for several standardsaccepted 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.2The "XML Advanced Electronic Signatures (XAdES)"280 standard was developed by theEuropean Telecommunications Standard Institute (ETSI). XAdES signatures not only fulfilthe requirements of the advanced electronic signature under the EU Directive, they alsowarrant additional non-repudiation and long-term validity. XAdES is an extension of XMLSignature.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/
  • 114. SAGA 4.0 115In Germany, XAdES is used, for instance, by Deutsche Posts Signtrust. There are severalcommercial suppliers of programs which process documents for storage on the basis ofXAdES.8.6.8 Interchange formats for graphics Mandatory: Graphics Interchange Format (GIF) v89aIn view of its widespread use, Graphics Interchange Format (GIF)281 should be used toexchange graphics and diagrams. GIF graphic files are compressed with a colour depth of256 colours (8 bits per pixel. Mandatory: Joint Photographic Experts Group (JPEG)The Joint Photographic Experts Group282 (JPEG) format should be used to exchangephotographs. This format supports changes in the compression factor and the definition ofdensity, so that a compromise between file size, quality and use is facilitated. JPEG can beused to store colour and grey-value images with 16.7 million colours (24-bit colourinformation). This format is supported by a host of graphic and presentation programs.Conventional compression in JPEG results in losses, however, it does achieve highcompression rates. JPEG is not suitable for graphics with similar colour surfaces andstrongly contrasting colour transitions (example: characters). Recommended: Portable Network Graphics (PNG) v1.2The Portable Network Graphics283 (PNG) format can be used. This format is license-free. Itsupports 16 million colours, transparency, loss-free compression, incremental display ofgraphics (beginning with the gross structure until the file is completely transmitted) andthe identification of damaged files. The format was standardized by ISO (ISO/IEC15948:2003284). Recommended: Tagged Image File Format (TIFF) v6.0TIFF285 can be used for saving bit-mapped graphics. TIFF is supported by all conventionalgraphic and presentation programs. In order to achieve maximum interoperability, theproperties of the "Baseline TIFF"286 must be used exclusively. TIFF can be used when theformat must be capable of presenting documents consisting of several pages. TIFF is281 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/en283 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.
  • 115. 116 SAGA 4.0particularly suitable for scanned text documents (b/w graphics or graphics with greyshades). Recommended: Geo Tagged Image File Format (GeoTIFF)GeoTIFF287 is an extension of TIFF v6.0. A geo-reference is additionally featured in the fileheader so that contrary to conventional TIFF, the geo-reference file *.tfw does not have to becreated. The GeoTIFF format is supported by established geo-information systems. Under observation: Joint Photographic Experts Group 2000 (JPEG2000) / Part 1JPEG 2000288 is the successor to JPEG and is not yet widely used. Offering the same quality, itfeatures higher compression than JPEG. Together with the use of metadata, JPEG 2000 issuitable for recording geo-data289. Browser support for JPEG 2000 is only available usingplug-ins. Classification of JPEG 2000 is limited to the first part of the ISO standard290 becausethis contains the core functionality and is the most useful standard.8.6.9 Animation Mandatory: Animated Graphics Interchange Format (Animated GIF) v89aAnimation means moving features in graphics displayed on a website. Animated GIF, avariant 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 theirsequence, display time and number of repetitions.8.6.10 Audio and video data8.6.10.1 Interchange formats for audio and video files Recommended: QuicktimeThe customary Quicktime format292 should be used to exchange video sequences. A suitableplug-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 PictureExperts Group and standardized as ISO/IEC-14496293. MP4 is known as part 14 of the MPEG-4287 Refer to http://www.remotesensing.org/geotiff/288 Refer to http://www.jpeg.org/jpeg2000/289 Refer to OGC: "GML in JPEG 2000 Interoperability Experiment (GMLJP2)", http://www.opengeospatial.org/standards/gmljp2290 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/
  • 116. SAGA 4.0 117standard. MP4 is an open, manufacturer-independent standard and this format issupported 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. Itis 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 applicationin question. Theora296 can be used for video data. Speex297 is suitable for audio files with lowquality requirements, for example, voice recordings. Vorbis298, which features a quality thatis equivalent to MP3, can be used for audio files with normal quality requirements. Loss-freeAudio-Codec FLAC299 can be used for cases where maximum quality is required. Under observation: Windows Media Video (WMV) v9The quality of Windows Media Video (WMV) format is better than that of Quicktimeformat. However, patents make the use of WMV format difficult for open sourcedevelopers. Under observation: RealMedia v10RealMedia from RealNetworks300 is the container format for the RealAudio audio formatand the RealVideo video format. All these formats are proprietary. The quality of RealVideoexceeds that of the Quicktime format. The free player is available for all conventionalplatforms as well as some mobile devices. RealMedia should only be used if the audio-videodata is not to be archived. It is ensured that the files can be played today, however, with aview to the future, it must be feared that no more players will be available for what will bethen old RealMedia formats.8.6.10.2 Interchange formats for audio and video streamingIn contrast to "normal" audio and video sequences, audio and video streaming offers aformat that enables playing already during transmission. This enables live transmission ofvideos, whereas "normal" audio and video files must be completely transmitted first beforethey can be started. This area is occasionally characterized by a slightly confusing mix ofsuppliers, products, container and content formats. Since SAGA does not intend torecommend products, recommendations will be given for the container format only.What is important here is that the recommendations should be compatible - to themaximum extent possible – with customary streaming servers and client products. Due to294 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/
  • 117. 118 SAGA 4.0the fact that this area has been a field of strong competition for several years, the differentproducts are currently highly compatible in terms of the formats supported. Mandatory: Hypertext Transfer Protocol (HTTP) v1.1In order to reach as many citizens as possible, the server product selected should enable thetransport of streaming data via HTTP301. Recommended: QuicktimeIn order to achieve the maximum possible degree of compatibility between the streamingsignal and commonly used web browsers and video clients and/or plug-ins, Quicktimeformat302 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 thecodec, 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 streamaudio 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) v9Analogous to section 8.6.10.1 on page 116. Under observation: RealMedia v10Analogous to section 8.6.10.1 on page 116.When RealMedia is used to stream applications, it must also be considered that the pricesfor the RealMedia servers, called Helix servers, are high compared to Windows MediaQuicktime. However, the Helix Universal servers also support Windows Media andQuicktime.8.6.11 Interchange formats for geo-informationThe standards listed below for exchanging geo-information are used in the geo-services insection 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 126302 Refer to http://quicktime.apple.com/303 Published as RFC 3533, refer to http://www.ietf.org/rfc/rfc3533.txt
  • 118. SAGA 4.0 119 Recommended: Geography Markup Language (GML) v3.1.1GML304 is a markup language used to interchange and save geographical information invector format which considers spatial and non-spatial properties. This specification wascarried out by the Open Geospatial Consortium (OGC)305. GML does not contain anyinformation 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.2GML 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 andminimize network load. Mandatory: ZIP v2.0Compressed 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 thatis included in ISO/IEC standard 9945308.In order to create a file archive, all the files must first be compiled with TAR to form anarchive 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 compressionleads 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/
  • 119. 120 SAGA 4.0In addition to the following technologies, the standards which were generally described forpresenting contents on computers should also be used for mobile devices, refer to sections8.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 GenerationPartnership Project (3GPP). 3GPP combines several standardization committees (includingETSI) and aims to draft technical specifications which precisely describe all aspects ofmobile communication technology. Under observation: Wireless Application Protocol (WAP) v2.0The Wireless Application Protocol (WAP)310 v2.0 is a specification for the development ofapplications that use wireless communication networks. Its main application is mobilecommunications. WAP includes the Wireless Markup Language (WML) v2.0. Compared toits predecessor version, the presentation possibilities of WAP v2.0 have become much moresimilar to those on the World Wide Web. With conventional web browsers, it is not possibleto read WML pages. This means that offers which are to be provided for mobile Internetapplications 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.0browsers. XHTMLMP supports various script languages, for example ECMAScript MobileProfile (ESMP), a subset of ECMA262312 without extensive computing and memory scriptfunctions.The majority of mobile devices meanwhile feature WAP 2.0 browsers. However, in the caseof mobiles phones, in general, and PDAs, in particular, there is a growing trend towardsweb browsers with full functionality. Under observation: Extensible Hypertext Markup Language (XHTML) Basic v1.0XHTML Basic v1.0313 is a standard for presenting HTML pages converted to XML forapplications which do not support the full presentation functionality of HTML (e.g. mobilephone or PDAs).XHTML Basic was expanded to XHTML Mobile Profile (XHTMLMP)314 which is contained inWAP v2.0. This means that documents which were written in XHTML Basic can be read withWAP-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
  • 120. SAGA 4.0 1218.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 serverapplications that communicate within an administration, refer to section 8.7.1.1, and clientapplications outside the administration which communicate with an administrationserver, refer to section 8.7.1.2.The data elements to be transmitted should be specified using the technologies describedin section 8.3 "Data models" on page 96 and section 8.6.6 "Interchange formats for data " onpage 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. ViaRMI, an object on a Java Virtual Machine (VM), can trigger methods of an object that runson 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.1SOAP316 should be used for communications between the party supplying the server and theuser of a server within the meaning of the SOA reference model317. SOAP can be used toexchange structured data as XML objects between applications or their components via anInternet protocol (e.g. via HTTP). Mandatory: Web Services Description Language (WSDL) v1.1The Web Services Description Language (WSDL) should be used for service definitionpurposes. WSDL is a standardized language318 that describes web services in such a mannerthat they can be used by other applications without the need to know further details of theimplementation or to use the same programming language. Mandatory: Java Message Service (JMS) v1.1JMS319 is used to generate, send, receive and read messages. JMS API defines a uniforminterface that enables Java programs to communicate messages to other massaging315 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
  • 121. 122 SAGA 4.0systems. The advantage of communication with messages is the loose link. JMS ensures thatthe messages are sent in an asynchronous and reliable manner.JMS should then be used when components communicating with each other are not to bedisclosed with a view to their interfaces (easier exchangeability) and when communicationbetween the components is to be generally asynchronous and error-tolerant. Mandatory: J2EE Connector Architecture (JCA) v1.5JCA320 should be used to integrate existing systems into Java applications and/or tocommunicate with them. This means that the systems must provide so-called resourceadapters. A resource adapter must be created just once for each legacy system and can thenbe reused in all environments for Java Enterprise Editions (Java EE). The JCA resourceadapter frequently uses messages, such as JMS, in order to communicate with legacysystems. Recommended: Java Language Mapping to OMG IDLThe most well-known implementation of the Java Language Mapping to OMG IDL321specification, which was published by OMG, is Remote Method Invocation over InternetInter ORB Protocol (RMI-IIOP) from Sun.Java RMI-IIOP322 is an integral part of Java Standard Edition (Java SE) and hence also part ofthe Enterprise Edition (Java EE). Distributed Java applications can communicate via RMI-IIOP with remote applications via CORBA. RMI-IIOP communication can be carried out withall Object Request Brokers which conform to the latest CORBA specification 2.3.1323. Theremote applications are hence not limited to the Java language. Recommended: Web Services (WS) Security v1.1WS-Security324 is an OASIS standard for secure web services. It defines upgrades of the SOAPprotocol in order to provide and ensure confidentiality, integrity and the binding effect ofSOAP messages for securing web services. WS-Security supports the signing and encryptionof SOAP messages based on XML Signature and XML Encryption. The use of differentsecurity models and different cryptographic method must be possible.WS-Security also enables different "security tokens", i.e. data formats which warrantspecific identities or properties, e.g. X.509 certificates, Kerberos Tickets, SAML tokens orencrypted keys.The specification of WS-Security consists of the "WS-Security Core Specification 1.1" and thefollowing profiles:a. Username Token Profile 1.1b. X.509 Token Profile 1.1320 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
  • 122. SAGA 4.0 123c. SAML Token profile 1.1d. Kerberos Token Profile 1.1e. Rights Expression Language (REL) Token Profile 1.1f. SOAP with Attachments (SWA) Profile 1.1The token profiles specify how the different tokens can be used in SOAP. Under observation: Universal Description, Discovery and Integration (UDDI) v2.0The UDDI protocol is the basis for designing a standardized, interoperable platform thatpermits the simple, fast and dynamic search for web services. The further development ofUDDI is being promoted within the scope of OASIS325. UDDI is based on standards issued bythe 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 administrationWeb services should be used for access by client applications via the Internet to serverapplications at administrations.By providing a web service layer for an existing server application, client systems areenabled 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 usesSOAP to communicate with other components via the HTTP standard protocol. XML is usedfor the message content itself. XML was already described in section 8.3 "Data models" onpage 96 as a universal and primary standard for exchanging data between all theinformation systems relevant for administrative purposes.The Web Service Interoperability Organization (WS-I) defines profiles of existing standardsin order to facilitate the compilation of the required standards. The profile to be applied isWS-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.1Analogous to section 8.7.1.1 on page 121. Mandatory: Web Services Description Language (WSDL) v1.1Analogous to section 8.7.1.1 on page 121. Recommended: Web Services (WS) Security v1.1Analogous 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
  • 123. 124 SAGA 4.0 Under observation: Universal Description, Discovery and Integration (UDDI) v2.0Analogous to section 8.7.1.1 on page 121.8.7.2 Network protocols Mandatory: Internet Protocol (IP) v4The federal administrations IT environment currently uses IP v4 (RFC 791327, RFC 1700328) inconjunction with TCP (Transmission Control Protocol, RFC 793329) and UDP (User DatagramProtocol, RFC 768330).When new components of a system are to be introduced, these new components shouldsupport 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 thestandard on the Internet. DNS refers to a hierarchical name server service at central pointsof the Internet. This is where a server name entered is converted to the pertinent IP address. Under observation: Internet Protocol (IP) v6IP 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 to128 bits in order to permit addressing of multi-embedded and mobile IP-based systems infuture.IP v6 includes IPsec (IP-Security Protocol) which is chiefly used in the VPN (Virtual PrivateNetwork) area and which can also be used independent of IP v6. Thanks to the use of VPNswith secure encryption methods, the transport channel and the authentication of terminalsystems is ensured in the manner required, for instance, for wireless networks (WirelessLocal Area Network – WLAN) and also for home offices or in site networking. Informationon IPsec and VPN is available, for instance, from the German Federal Office for InformationSecurity334.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.txt332 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.txt334 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
  • 124. SAGA 4.0 1258.7.3 E-mail communication Mandatory: Simple Mail Transfer Protocol (SMTP) / Multipurpose Internet Mail Exten sions (MIME) v1.0E-mail protocols that comply with the SMTP / MIME335 specifications for exchangingmessages (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 page105. Mandatory: Post Office Protocol (POP) v3 / Internet Message Access Protocol (IMAP) v4rev1In exceptional cases, it may be necessary to offer electronic mailboxes. In this case, POP3337or IMAP338 should be used as the commonly used standards. Mandatory: Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 1 to Part 6The secure exchange of e-mails is one possible application for the "communication"interaction stage. Secure e-mail communication includes securing e-mails during theirtransmission 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 forsecuring documents, including e-mail attachments.Taking the basic functions of the electronic signature, encryption and authentication, theISIS-MTT specification considers a host of applications for processes to secure electronicbusiness (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 andsometimes make use of telephone systems with Voice-over-IP (VoIP). With this form ofcommunication, the interfaces in the field of presentation must be offered to the outsideworld and the interfaces in the backend with eGovernment applications must be madeavailable (Computer Telephony Integration – CTI). This means that context-related VoIPconnections to the respective specialized officers or call-centre employees can be offered tocustomers on websites and data received is displayed to the employee without mediainconsistencies.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
  • 125. 126 SAGA 4.0 Recommended: H.323The protocol for signalling according to the ITU-Ts standard H.323339 together with theprotocols that belong to this family should be used to transport data for IP telephony. Under observation: Session Initiation Protocol (SIP) v2.0SIP 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 analternative to H.323.8.7.5 Application protocolsSection 8.1.4 "Implementation of the security concept" on page 93 deals with theconnection 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 oneof the oldest Internet services. FTP enables the shared use of files, it offers usersstandardized user interfaces for different file system types, and transfers data in an efficientand reliable manner. FTP is typically somewhat faster than HTTP when larger files are to bedownloaded.Since FTP does not encrypt any data, including passwords, before sending, it should not beused 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.1HTTP v1.1 (RFC 2616342) should be used for communications between the client and webserver. However, web servers should also support HTTP v1.0 (RFC 1945343) in addition toversion 1.1. The HTTP State Management Mechanism (RFC 2965344) standard should beadopted 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 "webfolders" (refer to WebDAV on page 128). Chat systems can initiate the reloading of websitesvia 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
  • 126. SAGA 4.0 127 Mandatory: Online Service Computer Interface (OSCI) Transport v1.2The Online Service Computer Interface (OSCI)345 is the result of the MEDIA@Kommcompetition. OSCI covers a host of protocols which are suitable for eGovernmentrequirements and which are implemented by the OSCI steering group. The aim is tosupport transactions in the form of web services and their complete handling via theInternet.OSCI Transport 1.2 is that part of "OSCI" which is responsible for the cross-section tasks in thesecurity area. The existence of a central intermediary which can perform added-valueservices without jeopardizing confidentiality at the business case data level is acharacteristic feature of the secure implementation of eGovernment processes using OSCI.As a secure transmission protocol, it enables binding online transactions (even inconformance 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 standardizesboth message contents as well as transport and security functions and is based oninternational 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 languagesc. 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.0TLS346 is a cryptographic protocol that ensures the integrity and confidentiality of acommunication connection on the World Wide Web. It was developed from the SecureSockets Layer (SSL) protocol. The SSL v3 standard, which was still mandatory in SAGA version2.1, is listed in the Right of Continuance List. For security reasons, older SSL standards shouldno 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 agencys server in relationto the client of the communication partner in order to confirm to the latter that it is reallyconnected to the public agencys server. Double-ended authentication of client and servercan 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
  • 127. 128 SAGA 4.0a. 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 contentsd. Symmetric message authentication (via MACs) and protection against reply attacksThe principles of operation of TLS are described in detail in section 5.2.2 of the Guideline forthe Introduction of the Electronic Signature and Encryption in the Administration issued bythe Co-operation Committee for Automatic Data Processing for the Federal-government,Federal-state Government and Municipal Administration Sector (KoopA ADV)347. In TLS, thecombination of different methods is referred to as a "cipher suite". A TLS cipher suite alwayscontains four cryptographic algorithms: a signature method, a key exchange method, asymmetric 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. Usinga standardized authentication procedure, it enables the opening of an encrypted tunnelbetween the client and server system and then permits encrypted user data to be sent andreceived via the transport layer. The different open-source and commercialimplementations of this protocol enable strong encryption of user data and allow, forinstance, remote control of remote computers and file transfer (SSH-FTP). This means thatthere 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 beused as an extension of HTTP for writing and changing files in networks. It is hence analternative to FTP. In contrast to FTP, when data is transmitted with WebDAV, no additionalport has to be released because WebDAV uses the HTTP port 80. Write access based onpasswords should be encrypted, e.g. via HTTPS or TLS. However, not all applications thatsupport WebDAV also support so-called encryption mechanisms. Under observation: Transport Layer Security (TLS) v1.1Adopted in April 2006, TLS v1.1350 is a further development of TLS v1.0 that featuresimproved 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/
  • 128. SAGA 4.0 129dateninfrastruktur Deutschland [Geo-data infrastructure Germany] (GDI-DE)352 and areorientated 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.0The Catalogue Services Specification v2.0 – ISO Metadata Application Profile353 is anapplication profile for catalogue services which was adopted by the OGC. The profile refersto the CSW base specification of OGC and the metadata specifications of ISO (ISO 19115, ISO19119). It should be used to implement standard-compliant metadata searches. Recommended: Web Map Service Deutschland (WMS-DE) v1.0The aim of the WMS-DE354 profile is to define in a binding manner the requirements ofGeodateninfrastruktur Deutschland (GDI-DE) for a Web Map Service (WMS). With WMSservices which use this profile, the user can achieve a nation-wide presentation bycombining the digital maps and data of various WMS services. The binding parameterswithin the scope of GDI-DE should benefit both suppliers during the establishment ofservices as well as users during queries. Recommended: Web Coverage Service (WCS) v1.0.0WCS355 enables access to multi-dimensional grid data. This service is particularly suitablefor submitting grid data, e.g. in shop solutions, for providing measured values in the formof time series, and for supplying digital terrain models. Recommended: Web Feature Service (WFS) v1.0WFS 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.1Compared to its predecessor version 1.0.0, WFS v1.1.0357 is not yet so widely used. Data isexchanged 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/
  • 129. 130 SAGA 4.0 Recommended: Simple Feature Access – Part 2: SQL option (SFA-2) v1.1.0SFA-2358 defines interfaces for accessing geo-data objects (features). Along with OGC, thisstandard 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 inuse even in the future (e.g. ERP, mainframe transaction processing, database systems andother legacy applications). Depending on the operating modes supported, these legacysystems 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) andc. 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" orb. 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 beachieved, the time and budget available, as well as the functions to be supported during theintegration of the legacy system.The following sections discuss different solution concepts which have proven to be suitablewith the three above-mentioned operating modes.The data elements to be transmitted should be specified using the technologies describedin 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) v3LDAP v3 (RFC 4510 - 4519360) is an X.500-based Internet protocol which is optimized withregard to hierarchically structured information and which is used for directory serviceaccess. Under observation: Universal Description, Discovery and Integration (UDDI) v2.0Analogous 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
  • 130. SAGA 4.0 131 Under observation: Directory Services Markup Language (DSML) v2DSML361 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 toaccess 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.0ebXML RS describes the services and protocols offered by an ebXML-compliant registry. AnebXML registry is a system that safely administers any particular content and the related,standardized metadata. ebXML RIM describes the pertinent information model. Thetechnologies should be used together.ebXML RS v3.0362 and ebXML RIM v3.0363 were adopted by OASIS364 on 1 May 2005 as OASISstandards. Compared to version 2.0, version 3.0 adds many useful features, such asversioning repository contents.8.8.2 Access to databases Mandatory: Java Database Connectivity (JDBC) v3.0JDBC365 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" onpage 121. Mandatory: Simple Object Access Protocol (SOAP) v1.1Analogous to section 8.7.1.1 "Middleware communication within the administration" onpage 121. Mandatory: Web Services Description Language (WSDL) v1.1Analogous to section 8.7.1.1 "Middleware communication within the administration" onpage 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
  • 131. 132 SAGA 4.0 Mandatory: Java Message Service (JMS) v1.1Analogous to section 8.7.1.1 "Middleware communication within the administration" onpage 121. Mandatory: J2EE Connector Architecture (JCA) v1.5Analogous to section 8.7.1.1 "Middleware communication within the administration" onpage 121. Recommended: Java Language Mapping to OMG IDLAnalogous to section 8.7.1.1 "Middleware communication within the administration" onpage 121. Recommended: Web Services (WS) Security v1.1Analogous to section 8.7.1.1 "Middleware communication within the administration" onpage 121.8.9 EncryptionCryptographic algorithms for encryption can be applied to data and/or keys in order toensure 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, referto section 8.9.2 on page 132. Mandatory: RSAThe RSA method366 is the most important asymmetric method; it is also referred to as thepublic key method. During encryption, the bit sequence is encrypted using the public keyof the communication partner. After this, the resultant encrypted secret text can only bedecrypted to plain text by the holder of the private key. The security of this method is basedon the difficulty to factorize large natural numbers. Normal key lengths are 2048 and 4096bits. 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 anddecryption. These methods usually feature very high performance.366 RSA was named after its inventors: Ronald L. Rivest, Adi Shamir and Leonard Adleman
  • 132. 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 thatcan be either 128, 192 or 256 bits long. AES was published in October 2000 by the NationalInstitute of Standards and Technology (NIST)368.The Triple Data Encryption Standard (Triple-DES, also called 3DES), which was stillrecommended 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 theunderlying cryptographic algorithms. With regard to the "electronic signature" issue, referalso to section 4.5.1 on page 45. Mandatory: Cryptographic algorithms for the electronic signature according to the Federal Network AgencyEvery year, the Federal Network Agency publishes in the Federal Gazette thosecryptographic algorithms which can be considered to be suitable for at least the next sixyears with a view to the requirements of the Act on Digital Signature (SigG) and the DigitalSignature Ordinance (SigV)369. To this effect, the minimum dimensions of parameters, suchas block sizes and key lengths, are stated which are needed to ensure sufficient security. TheGerman Federal Office for Information Security (BSI) can classify further methods assuitable.An electronic signature for the purposes of the Act includes the following cryptographicalgorithms.8.10.1 Hashing dataA hash function reduces the data to be signed to a hash value, i.e. a bit sequence with a fixedlength. This then means that the hash value rather than the data itself is signed. Mandatory: Secure Hash Algorithm (SHA)-256SHA-256 (Secure Hash Algorithm)370, as a further development of SHA-1 (160-bit long hashvalue), 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
  • 133. 134 SAGA 4.0 Recommended: Secure Hash Algorithm (SHA)-224 / Secure Hash Algorithm (SHA)-384 / Secure Hash Algorithm (SHA)-512SHA-224, SHA-384 und SHA-512 (Secure Hash Algorithm)371 are further developments ofSHA-1 (160-bit long hash value) and constitute cryptographic hash functions that generatelonger 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. Thesignature method is dependent on a key pair which consists of a private (i.e. secret) key forsigning (generating) and the pertinent public key for verifying (checking) the signature. Mandatory: RSAAnalogous to section 8.9.1 "Asymmetric encryption methods" on page 132, RSA should beused for the asymmetric signature method. Recommended: Digital Signature Algorithm (DSA)The Digital Signature Algorithm (DSA)372 is the signature method that was specified in theUS Digital Signature Standard (DSS) in 1991. DSA is a pure signature algorithm. Although theUS government has obtained a patent for DSS, its use is free. DSA is less widespread thanRSA. The Federal Network Agencys algorithm catalogue foresees qualified electronicsignatures 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 longerrecommends 1024-bit keys.8.10.3 Key managementAs a precondition for applications to use electronic signatures, it must be possible to assignpublic electronic keys (public keys) to real individuals or institutions. In order to achieveinteroperability 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) v2XKMS373 specifies protocols for the registration and distribution of public keys. Theprotocols were designed for interaction with XML Signature and XML Encryption and arehence used for XML-based communications, e.g. web services. The specification consists oftwo parts, i.e. the XML Key Registration Service Specification (X-KRSS) and the XML KeyInformation Service Specification (X-KISS).371 Published as FIPS PUBS 180-2, refer to http://csrc.nist.gov/publications/fips/fips180-2/fips180- 2.pdf372 Published as FIPS 186-2, refer to http://csrc.nist.gov/publications/fips/fips186-2/fips186-2- change1.pdf373 Refer to http://www.w3.org/TR/xkms2/
  • 134. SAGA 4.0 135Clients can use relatively simple XKMS queries to find and validate public keys, with relayservers 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 asmicroprocessor cards. In contrast to chip cards which are used to only save data (memorycards), smartcards can also process data. Smartcards can serve as a Personal SecurityEnvironment (PSE), in order to safely store trustworthy certificates and keys, and also as a(secure) signature generation unit.374A distinction is made between contact smartcards and contactless smartcards. Whilstcontact smartcards feature a visible, exterior contact surface, contactless smartcardsestablish contact with the reader devices by wireless communication (Radio FrequencyIDentification – RFID).8.11.1 Contact smartcards Mandatory: Identification Cards - Integrated circuit cardsContact smartcards should conform to the ISO/IEC 7816375 standard. The standard describes,for instance, dimensions, positioning contacts and labelling, electrical properties as well astransmission protocols.8.11.2 Contactless smartcards Mandatory: Identification Cards - Contactless integrated circuit cardsContactless smartcards with a transmission rate of up to approx. 847 kbps – correspondingto a range of up to 0.1m – should conform to the ISO/IEC 14443376 standard. The standarddescribes in four parts the design, function and operation of these smartcards. Theelectronic passport377 is based on this standard. The electronic ID card, which is currently inthe 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.pdf375 Refer to http://www.iso.org/376 Refer to http://www.iso.org/377 Refer to http://www.epass.de/
  • 135. 136 SAGA 4.08.11.3 Reader units and interfaces for smartcards Mandatory: Technical guideline for federal-government eCard projects (BSI TR-03116) v1.0Smartcard applications which use cryptographic methods should consider the securityrequirements for the use of cryptographic methods in federal-government eCard projectsdescribed in technical guideline BSI TR-03116378 from the Federal Office for InformationSecurity (BSI) . Mandatory: Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 7Components 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.0PC/SC380 specifies an interface between card reader units and the applications. Under observation: OpenCard Framework (OCF) v1.2OCF381 specifies an interface between card reader units and the applications. Under observation: Secure Interoperable ChipCard Terminal (SICCT) v1.10SICCT382 describes a basic concept for application-independent terminals for smartcardsbased on ISO/IEC 7816 and ISO/IEC 14443383. Applications with high or very high securityrequirements 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 theauthenticity 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.pdf383 Refer to http://www.iso.org/
  • 136. SAGA 4.0 137 Recommended: Tagged Image File Format (TIFF) v6.0TIFF v6.0 should be used for the long-term archiving of graphics and b/w images. Maximuminteroperability is particularly important in this area of application. This is why onlyproperties 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 beused for long-term archiving of images, in particular, for photos. Recommended: Extensible Markup Language (XML) v1.0XML is suitable for long-term archiving, however, the related schemas and XSL files mustalso 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 ArchivalDescription (EAD)384, Encoded Archival Context (EAC)385 and the Metadata Encoding andTransmission 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 scienceand industry as well as with users under the leadership of InformatikzentrumNiedersachsen [Lower Saxon Computer Science Centre] and Staatliche ArchivverwaltungNiedersachsen [Lower Saxon state archive administration]. It defines principles388 thatshould 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/
  • 137. 138 SAGA 4.02. 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. Thisstandard recognized by ISO can be used to save the document contents, the document formand the metadata of the document in one archived file. The file can also be displayedwithout the original application. A barrier-free presentation of contents is also provided. Under observation: Extensible Markup Language (XML) v1.1Analogous to section 8.6.6 "Interchange formats for data " on page 109.
  • 138. SAGA 4.0 139Appendix A References[APEC] National Office for the Information Economy / CSIRO: APEC e-Business: What do Users need?, 2002 http://nla.gov.au/nla.arc-25067 http://www1.cmis.csiro.au/Reports/APEC_E-commerce.pdf[BOL] Federal Ministry of the Interior (editor): BundOnline 2005: Umsetzungsplan 2004 – Status und Ausblick, Dresden 2004 http://www.kbst.bund.de/ (in the area of > eGovernment > Initiatives > BundOnline 2005 > Implementation plan and final report > 2004 – implementation plan)[BSI 2005] German Federal Office for Information Security: ITIL und Informationssicherheit – Möglichkeiten und Chancen des Zusammenwirkens von IT-Sicherheit und IT-Service- Management, Berlin, 2005 http://www.bsi.de/literat/studien/ITinf/itil.pdf[e-GIF] Office of the e-Envoy: e-Government Interoperability Framework Version 6.0, 2004 http://www.govtalk.gov.uk/schemasstandards/egif.asp http://www.govtalk.gov.uk/documents/e-gif-v6-0(1).pdf Office of the e_Envoy: Technical Standards Catalogue Version 6.1, 2004 http://www.govtalk.gov.uk/documents/TSCv6-1_2004-11-15.pdf[FIPS-PUBS] National Institute of Standards and Technology (NIST), Information Technology Laboratory (ITL): Federal Information Processing Standards Publications, 2005 http://www.itl.nist.gov/fipspubs/[GDI-DE 2007] Geo-data infrastructure Germany: Architektur der Geodateninfrastruktur Deutschland, concept for the universal provision of geodata within the scope of eGovernment in Germany, version 1.0, 2007 http://www.gdi-de.org/de/download/GDI_ArchitekturKonzept_V1.pdf[IDABC] European Commission: Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens, 2005 http://europa.eu.int/idabc/
  • 139. 140 SAGA 4.0[IEEE 2000] Institute of Electrical and Electronics Engineers (IEEE): IEEE-Standard 1471-2000: Recommended Practice for Architectural Description of Software-Intensive Systems, 2000[ISO 1996] ISO/IEC 10746-3: Information technology – Open Distributed Processing – Reference Model: Architecture, Geneva 1996[ITG 2000] Informationstechnische Gesellschaft (ITG) im VDE: Electronic Government als Schlüssel der Modernisierung von Staat und Verwaltung. A memorandum by the specialist committee for administrative IT of Gesellschaft für Informatik e.V. (GI) and special unit 1 of Informationstechnische Gesellschaft (ITG) at the Association for Electrical, Electronic and Information Technologies (VDE), Bonn / Frankfurt 2000 http://mediakomm.difu.de/documents/memorandum.pdf[KBSt 2007] KBSt: IT-Architekturkonzept für die Bundesverwaltung, 2007 http://www.kbst.bund.de/architekturkonzept[Kudraß 1999] Kudraß, Thomas: Describing Architectures Using RM-ODP, online publication, 1999 http://www.imn.htwk-leipzig.de/~kudrass/Publikationen/OOPSLA99.pdf[Lenk et al. 2000] Lenk, Klaus / Klee-Kruse, Gudrun: Multifunktionale Serviceläden, Berlin 2000[Lenk 2001] Lenk, Klaus: Über Electronic Government hinaus Verwaltungspolitik mit neuen Konturen, paper at the 4th conference on administrative IT at the Federal University of Applied Administrative Sciences on 5 September 2001[v. Lucke et al. 2000] Lucke, Jörn von / Reinermann, Heinrich: Speyerer Definition von Electronic Government. Results of the research project "government and administration in the information age", online publication, 2000 http://foev.dhv-speyer.de/ruvii/Sp-EGov.pdf[New Zealand] State Services Commission, New Zealand: E-government in New Zealand, 2007 http://www.e-government.govt.nz/[Schedler et al. 2001] Schedler, Kuno / Proeller, Isabella: NPM, Berne / Stuttgart / Vienna 2001
  • 140. 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), 2007 http://www.bk.admin.ch/org/bk/00346/00348/index.html?lang=de[SIGA] eGovernment project group at the German Federal Office for Information Security (BSI): Sichere Integration von E-Government-Anwendungen, module of the eGovernment manual, 2003 http://www.bsi.bund.de/fachthem/egov/4_siga.htm
  • 141. SAGA 4.0 143Appendix B Overview of ClassifiedStandards.NET-Framework...............................................................................................................................100AAdvanced Encryption Standard (AES)...........................................................................................133AES......................................................................................................................................................133Animated GIF.....................................................................................................................................116Animated Graphics Interchange Format (Animated GIF) v89a................................................116ANSI/NISO Z39.85...............................................................................................................................97ArchiSig, Grundsätze für die beweiskräftige und sichere Langzeitarchivierung digitalsignierter Dokumente [principles for conclusive and secure long-term archiving ofelectronically signed documents]..................................................................................................137BBarrierefreie Informationstechnik Verordnung (BITV) [Barrier-free information technologyordinance].........................................................................................................................................105BITV....................................................................................................................................................105BPEL4WS............................................................................................................................................100BSI, E-Government-Handbuch [eGovernment manual]......................................................95, 104BSI, IT-Grundschutz-Kataloge [IT Baseline Protection Catalogues]...........................................94BSI TR-03116.......................................................................................................................................136BSI standard 100-1: Management systems for Information Security..........................................91BSI standard 100-2: IT baseline protection approach...................................................................92BSI-Standard 100-3: Risk analysis on the basis of IT baseline protection...................................93Business Process Execution Language for Web Services (BPEL4WS) v1.1...............................100CC# Language Specification..............................................................................................................99Cascading Style Sheets Language Level 2 (CSS2)..........................................................................107Catalogue Services Specification v2.0 – ISO Metadata Application Profile v1.0....................129CLI.........................................................................................................................................................99Comma Separated Value (CSV).......................................................................................................112Common Language Infrastructure (CLI)........................................................................................99Cryptographic algorithms for the electronic signature according to the Federal NetworkAgency................................................................................................................................................133CSS2.....................................................................................................................................................107
  • 142. 144 SAGA 4.0CSV.......................................................................................................................................................112DDC.........................................................................................................................................................97DCMI Metadata Terms.......................................................................................................................97Digital Signature Algorithm (DSA).................................................................................................134DIN 66001............................................................................................................................................95Directory Services Markup Language (DSML) v2..........................................................................131DNS......................................................................................................................................................124Domain Name System (DNS)...........................................................................................................124DSA......................................................................................................................................................134DSML....................................................................................................................................................131Dublin Core (DC).................................................................................................................................97EebXML Registry Information Model (ebXML RIM) v3.0.............................................................131ebXML Registry Services and Protocols (ebXML RS) v3.0.............................................................131ebXML RIM.........................................................................................................................................131ebXML RS............................................................................................................................................131ECMA-262..........................................................................................................................................108ECMA-334............................................................................................................................................99ECMA-335..........................................................................................................................................100ECMA-376..............................................................................................................................111, 112, 113ECMAScript Language Specification.............................................................................................108eGovernment manual.......................................................................................................................95Election Markup Language (EML) v4.0.........................................................................................109EML.....................................................................................................................................................109Entity Relationship Diagram (ERD).................................................................................................96ERD.......................................................................................................................................................96Extensible Hypertext Markup Language (XHTML) Basic v1.0....................................................120Extensible Hypertext Markup Language (XHTML) v1.0..............................................................107Extensible Markup Language (XML) v1.0...............................................................................109, 137Extensible Markup Language (XML) v1.1...............................................................................109, 138Extensible Stylesheet Language (XSL) v1.0....................................................................................107Extensible Stylesheet Language (XSL) v1.1....................................................................................108Extensible Stylesheet Language Transformations (XSLT) v1.0...................................................107Extensible Stylesheet Language Transformations (XSLT) v2.0...................................................108
  • 143. SAGA 4.0 145FFile Transfer Protocol (FTP)..............................................................................................................126FIPS 186-2............................................................................................................................................134FIPS 197...............................................................................................................................................133FIPS PUBS 180-2..................................................................................................................................133FTP.......................................................................................................................................................126GGeo Tagged Image File Format (GeoTIFF).....................................................................................116Geography Markup Language (GML) v2.1.2..................................................................................119Geography Markup Language (GML) v3.1.1...................................................................................119GeoTIFF...............................................................................................................................................116GIF v89a..............................................................................................................................................115GML v2.1.2...........................................................................................................................................119GML v3.1.1............................................................................................................................................119Gnu ZIP (GZIP) v4.3............................................................................................................................119Graphics Interchange Format (GIF) v89a......................................................................................115HH.323...................................................................................................................................................126Handlungsleitfaden 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]..................................................................................................94HTML............................................................................................................................................110, 113HTML v4.01........................................................................................................................................106HTTP v1.1......................................................................................................................................118, 126Hypertext Markup Language (HTML) v4.01...................................................................106, 110, 113Hypertext Transfer Protocol (HTTP) v1.1.................................................................................118, 126IIdentification Cards - Contactless integrated circuit cards.......................................................135Identification Cards - Integrated circuit cards.............................................................................135IMAP v4rev1.......................................................................................................................................125Industrial Signature Interoperability Specification – MailTrusT (ISIS-MTT) v1.1.....................93Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 1 to Part6...........................................................................................................................................................125Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 3........114Industrial Signature Interoperability Specification – MailTrust (ISIS-MTT) v1.1., Part 7........136Internet Message Access Protocol (IMAP) v4rev1........................................................................125Internet Protocol (IP) v4...................................................................................................................124
  • 144. 146 SAGA 4.0Internet Protocol (IP) v6...................................................................................................................124Interoperability Specification for ICCs and Personal Computer Systems (PC/SC) v2.0..........136IP v4.....................................................................................................................................................124IP v6.....................................................................................................................................................124ISIS-MTT v1.1........................................................................................................................................93ISIS-MTT v1.1., Part 1 to Part 6...........................................................................................................125ISIS-MTT v1.1., Part 3..........................................................................................................................114ISIS-MTT379 v1.1, Part 7....................................................................................................................136ISO 10646:2003..................................................................................................................................106ISO 15836-2003....................................................................................................................................97ISO 19005-1:2005...............................................................................................................................137ISO 19125-2.........................................................................................................................................130ISO/IEC 10746-3:1996..........................................................................................................................31ISO/IEC 10918-1:1994...................................................................................................................115, 137ISO/IEC 14443.....................................................................................................................................135ISO/IEC-14496..............................................................................................................................116, 118ISO/IEC 15444-1...................................................................................................................................116ISO/IEC 15445.......................................................................................................................106, 110, 113ISO/IEC 15948:2003...........................................................................................................................115ISO/IEC 16262.....................................................................................................................................108ISO/IEC 19503:2005......................................................................................................................96, 97ISO/IEC 19757-2:2003..........................................................................................................................97ISO/IEC 23270:2006............................................................................................................................99ISO/IEC 23271:2006...........................................................................................................................100ISO/IEC 26300:2006..............................................................................................................111, 112, 113ISO/IEC 279001....................................................................................................................................83ISO/IEC 7816.......................................................................................................................................135ISO/IEC TR 23272:2006.....................................................................................................................100ISO/PRF 19136......................................................................................................................................119IT-Grundschutz-Vorgehensweise v1.0 [BSI standard 100-2: IT baseline protection approach]...............................................................................................................................................................92IT-Grundschutzkataloge [IT Baseline Protection catalogues].....................................................83ITU-T.81........................................................................................................................................115, 137JJ2EE Connector Architecture (JCA) v1.5.................................................................................122, 132Java Database Connectivity (JDBC) v3.0.........................................................................................131Java EE v5.............................................................................................................................................98Java Language Mapping to OMG IDL.....................................................................................122, 132
  • 145. SAGA 4.0 147Java Message Service (JMS) v1.1.................................................................................................121, 132Java Network Launching Protocol (JNLP) v1.5..............................................................................102Java Platform, Enterprise Edition (Java EE) v5...............................................................................98Java Platform, Standard Edition (Java SE) v5..................................................................................99Java SE..................................................................................................................................................99Java Server Pages (JSP) v2.1...............................................................................................................107Java Servlet v2.5.................................................................................................................................107JCA...............................................................................................................................................122, 132JDBC.....................................................................................................................................................131JMS................................................................................................................................................121, 132JNLP.....................................................................................................................................................102Joint Photographic Experts Group (JPEG)...............................................................................115, 137Joint Photographic Experts Group 2000 (JPEG2000) / Part 1.......................................................116JPEG..............................................................................................................................................115, 137JPEG2000............................................................................................................................................116JSP v2.1.................................................................................................................................................107JSR-000054.........................................................................................................................................131JSR-000056 (Final Release)..............................................................................................................102JSR-000112...................................................................................................................................122, 132JSR-000154 (Maintenance Release)................................................................................................107JSR-000176...........................................................................................................................................99JSR-000244..........................................................................................................................................99JSR-000245.........................................................................................................................................107JSR-000914...................................................................................................................................121, 132KKerberos v5........................................................................................................................................105KoopA 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]........................................................................94LLDAP v3...............................................................................................................................................130Lightweight Directory Access Protocol (LDAP) v3.......................................................................130MManagement systems for Information Security............................................................................91Microsoft Windows .NET-Framework...........................................................................................100MIME v1.0...................................................................................................................................106, 125MP4...............................................................................................................................................116, 118
  • 146. 148 SAGA 4.0MPEG-4 Part 14 (MP4).................................................................................................................116, 118Multipurpose Internet Mail Extensions (MIME) v1.0...........................................................106, 125OOCF v1.2..............................................................................................................................................136Office Open XML (OOXML)..................................................................................................111, 112, 113Ogg...............................................................................................................................................117, 118Ogg Encapsulation Format (Ogg)............................................................................................117, 118Online Service Computer Interface (OSCI) Transport v1.2..........................................................127OOXML...................................................................................................................................111, 112, 113Open Document Format for Office Applications (OpenDocument) v1.0.....................111, 112, 113OpenCard Framework (OCF) v1.2...................................................................................................136OpenDocument v1.0............................................................................................................111, 112, 113OSCI Transport 1.2.............................................................................................................................127PPC/SC...................................................................................................................................................136PDF version 1.4......................................................................................................................110, 111, 112PDF version 1.5......................................................................................................................110, 112, 113PDF version 1.6......................................................................................................................110, 112, 113PDF/A-1................................................................................................................................................137PHP......................................................................................................................................................100PHP Hypertext Preprocessor (PHP) v5.x........................................................................................100PNG......................................................................................................................................................115POP3....................................................................................................................................................125Portable Document Format (PDF) v1.4..............................................................................110, 111, 112Portable Document Format (PDF) v1.5.............................................................................110, 112, 113Portable Document Format (PDF) v1.6.............................................................................110, 112, 113Portable Document Format Archive - 1 (PDF/A-1).........................................................................137Portable Network Graphics (PNG) v1.2...........................................................................................115Post Office Protocol (POP) v3...........................................................................................................125QQuicktime....................................................................................................................................116, 118RRDF.......................................................................................................................................................97RealMedia v10.............................................................................................................................117, 118Reference Model for Open Distributed Processing (RM-ODP69)................................................31
  • 147. SAGA 4.0 149Regular Language Description for XML New Generation (Relax NG)........................................97Relax NG..............................................................................................................................................97Remote Method Invocation (RMI)............................................................................................121, 131Remote Method Invocation over Internet Inter ORB Protocol (RMI-IIOP) ..............................122Resource Description Framework (RDF).........................................................................................97RFC 1034/RFC 1035............................................................................................................................124RFC 1510..............................................................................................................................................105RFC 1700.............................................................................................................................................124RFC 1939.............................................................................................................................................125RFC 1945.............................................................................................................................................126RFC 1952..............................................................................................................................................119RFC 2045 to RFC 2049...............................................................................................................106, 125RFC 2246.............................................................................................................................................127RFC 2460............................................................................................................................................124RFC 2518.............................................................................................................................................128RFC 2616......................................................................................................................................118, 126RFC 2821.............................................................................................................................................125RFC 2965............................................................................................................................................126RFC 3041.............................................................................................................................................124RFC 3261.............................................................................................................................................126RFC 3275..............................................................................................................................................114RFC 3501.............................................................................................................................................125RFC 3533.......................................................................................................................................117, 118RFC 4251 - 4256..................................................................................................................................128RFC 4346.............................................................................................................................................128RFC 4510 - 4519..................................................................................................................................130RFC 4810..............................................................................................................................................112RFC 768...............................................................................................................................................124RFC 791................................................................................................................................................124RFC 793...............................................................................................................................................124RFC 959..............................................................................................................................................126Risikoanalyse auf der Basis von IT-Grundschutz v2.0 [BSI-Standard 100-3: Risk analysis onthe basis of IT baseline protection]..................................................................................................93RM-ODP................................................................................................................................................31RMI................................................................................................................................................121, 131RMI-IIOP.....................................................................................................................................122, 132Role models and flow charts............................................................................................................95RSA...............................................................................................................................................132, 134
  • 148. 150 SAGA 4.0SSAML...................................................................................................................................................104Secure Hash Algorithm (SHA)-224.................................................................................................134Secure Hash Algorithm (SHA)-256.................................................................................................133Secure Hash Algorithm (SHA)-384.................................................................................................134Secure Hash Algorithm (SHA)-512..................................................................................................134Secure Interoperable ChipCard Terminal (SICCT) v1.10..............................................................136Secure Shell v2 (SSH-2)......................................................................................................................128Security Assertion Markup Language (SAML) v2.0......................................................................104Session Initiation Protocol (SIP) v2.0..............................................................................................126SFA-2...................................................................................................................................................130SHA-224..............................................................................................................................................134SHA-256..............................................................................................................................................133SHA-384..............................................................................................................................................134SHA-512...............................................................................................................................................134Short Message Services (SMS)..........................................................................................................120SICCT..................................................................................................................................................136Simple Feature Access – Part 2: SQL option (SFA-2) v1.1.0............................................................130Simple Mail Transfer Protocol (SMTP)............................................................................................125Simple Object Access Protocol (SOAP) v1.1.......................................................................121, 123, 131SIP........................................................................................................................................................126SMIL.....................................................................................................................................................113SMS......................................................................................................................................................120SMTP...................................................................................................................................................125SOAP......................................................................................................................................121, 123, 131SSH-2...................................................................................................................................................128Synchronized Multimedia Integration Language (SMIL) v2.0...................................................113TTagged Image File Format (TIFF) v6.0....................................................................................115, 137Tape ARchive (TAR)...........................................................................................................................119TAR.......................................................................................................................................................119Technical guideline for federal-government eCard projects (BSI TR-03116) v1.0...................136Text.......................................................................................................................................................111TIFF...............................................................................................................................................115, 137TLS v1.0................................................................................................................................................127TLS v1.1................................................................................................................................................128Transport Layer Security (TLS) v1.0.................................................................................................127Transport Layer Security (TLS) v1.1..................................................................................................128
  • 149. SAGA 4.0 151UUDDI....................................................................................................................................123, 124, 130UML......................................................................................................................................................96Unicode v4.x UTF-16.........................................................................................................................106Unicode v4.x UTF-8...........................................................................................................................106Unified Modeling Language (UML) v. 2.0.......................................................................................96Universal Description, Discovery and Integration (UDDI) v2.0..................................123, 124, 130UTF-16.................................................................................................................................................106UTF-8..................................................................................................................................................106WWAP v2.0............................................................................................................................................120WCS v1.0.............................................................................................................................................129Web Coverage Service (WCS) v1.0.0...............................................................................................129Web Feature Service (WFS) v1.0......................................................................................................129Web Feature Service (WFS) v1.1.......................................................................................................129Web Map Service Deutschland (WMS-DE) v1.0............................................................................129Web Services (WS) Security v1.1.......................................................................................122, 123, 132Web Services Business Process Execution Language (WS-BPEL) v2.0......................................100Web Services Description Language (WSDL) v1.1...........................................................121, 123, 131WebDAV.............................................................................................................................................128WFS v1.0.0..........................................................................................................................................129WFS v1.1.0...........................................................................................................................................129Windows Media Video (WMV) v9............................................................................................117, 118Wireless Application Protocol (WAP) v2.0....................................................................................120WMS-DE.............................................................................................................................................129WMV.............................................................................................................................................117, 118WS-BPEL v2.0.....................................................................................................................................100WS-Security........................................................................................................................122, 123, 132WSDL.....................................................................................................................................121, 123, 131WWW Distributed Authoring and Versioning (WebDAV)........................................................128XXAdES..................................................................................................................................................114XForms v1.0........................................................................................................................................108XHTML Basic v1.0..............................................................................................................................120XHTML v1.0........................................................................................................................................107XKMS...................................................................................................................................................134XMI.................................................................................................................................................96, 97
  • 150. 152 SAGA 4.0XML Advanced Electronic Signatures (XAdES) v1.2......................................................................114XML Encryption.................................................................................................................................114XML Key Management Specification (XKMS) v2..........................................................................134XML Metadata Interchange (XMI) v2.x.....................................................................................96, 97XML Schema Definition (XSD) v1.0...................................................................................................96XML Signature...................................................................................................................................114XML v1.0......................................................................................................................................109, 137XML v1.1.......................................................................................................................................109, 138XSD.......................................................................................................................................................96XSL v1.0...............................................................................................................................................107XSL v1.1................................................................................................................................................108XSLT v1.0.............................................................................................................................................107XSLT v2.0............................................................................................................................................108ZZIP v2.0................................................................................................................................................119
  • 151. SAGA 4.0 153Appendix C Abbreviations3DES Triple Data Encryption StandardAES Advanced Encryption StandardAG Public limited company in GermanyAPEC Asia-Pacific Economic CooperationAPI Application Programming InterfaceArchiSig Conclusive and secure long-term archiving of electronically signed documentsBGG Law on equal opportunities for the disabledBIT Federal Office for Information TechnologyBITV Barrier-free information technology ordinanceBMI Federal Ministry of the InteriorBMP Windows BitmapBNetzA Federal Network Agency for electricity, gas, telecommunications, post and railwaysBOL 2005 BundOnline InitiativeBPEL4WS Business Process Execution Language for Web ServicesBSI German Federal Office for Information SecurityCA Certification AuthorityCC VBPO The "workflow management, processes and organization" competence centreCEN Comité Européen de NormalisationCMS Content Management SystemCORBA Common Object Request Broker ArchitectureCSIRO Commonwealth Scientific and Industrial Research OrganisationCSS Cascading Style Sheets LanguageCSV Character Separated ValueCSW Web Catalogue ServiceCTI Computer Telephony IntegrationDCMI Dublin Core Metadata InitiativeDES Data Encryption StandardDIN The German Institute for Standardization
  • 152. 154 SAGA 4.0DNS Domain Name SystemDOMEA Document management and electronic archiving in IT-based workflowsDRV German Federal Pension InsuranceDSA Digital Signature AlgorithmDSML Directory Services Markup LanguageDSS Digital Signature StandardDV Data processingDVDV German Directory of Administrative ServicesebXML Electronic Business using XMLECMA European Computer Manufacturers AssociationOFA One-for-alle-GIF E-Government Interoperability FrameworkEJB Enterprise JavaBeansEML Election Markup LanguageER Entity RelationshipERP Enterprise Resource PlanningETSI European Telecommunications Standards InstituteEU European UnionFinTS Financial Transaction ServicesFIPS-PUBS Federal Information Processing Standards PublicationsFLAC Free Lossless Audio CodecFMS Formular Management SystemFTP File Transfer ProtocolG2B Government to BusinessG2C Government to CitizenG2E Government to EmployeeG2G Government to GovernmentGDI-DE Geo-data infrastructure GermanyGI Gesellschaft für Informatik e.V.GIF Graphics Interchange FormatGML Geography Markup LanguageGSM Global System for Mobile CommunicationsHTML Hypertext Markup Language
  • 153. SAGA 4.0 155HTTP Hypertext Transfer ProtocolHTTPS Secure Hypertext Transfer ProtocolIANA Internet Assigned Numbers AuthorityIDABC Interoperable Delivery of European eGovernment Services to public Admin­ istrations, Businesses and CitizensIEC International Electrotechnical CommissionIETF Internet Engineering Task ForceIIOP Internet Inter-ORB ProtocolIMAP Internet Message Access ProtocolIP Internet ProtocolIPsec Internet Protocol SecurityISIS Industrial Signature Interoperability SpecificationISIS-MTT Industrial Signature Interoperability Specification - MailTrusTISMS Information Security Management SystemISO International Organization for StandardizationIT Information technologyITG Informationstechnische Gesellschaft im VDEITIL IT Infrastructure LibraryITU International Telecommunication UnionITU-T ITU Telecommunication Standardization SectorIVBB Berlin-Bonn Information NetworkIVBV Federal Administration Information NetworkJ2EE Java 2 Platform, Enterprise EditionJAAS Java Authentication and Authorization ServiceJava EE Java Platform, Enterprise EditionJava SE Java Platform, Standard EditionJAXP Java API for XML ParsingJCA J2EE Connector ArchitectureJDBC Java Database ConnectivityJMS Java Message ServiceJMX Java Management ExtensionsJNDI Java Naming and Directory InterfaceJNLP Java Network Launching Protocol
  • 154. 156 SAGA 4.0JPEG Joint Photographic Experts GroupJRE Java Runtime EnvironmentJSP Java Server PagesJSR Java Specification RequestsJTA Java Transaction APIKBSt Co-ordinating and Advisory Agency of the Federal Government for Information Technology in the Federal Administration at the Federal Ministry of the InteriorKoopA ADV Co-operation Committee for Automatic Data Processing for the Federal- government, Federal-state Government and Municipal Administration SectorLDAP Lightweight Directory Access ProtocolMAC Message Authentication CodeMIME Multipurpose Internet Mail ExtensionsMIT Massachusetts Institute of TechnologyMOF Meta Object FacilityMPEG Moving Picture Experts GroupMTT MailTrusTNAT Network Address TranslationNISO National Information Standards OrganizationNIST National Institute of Standards and TechnologyOASIS Organization for the Advancement of Structured Information StandardsOCSP Online Certificate Status ProtocolODF OpenDocument FormatOGC Open Geospatial ConsortiumOMG Object Management GroupOOXML Office Open XMLOSCI Online Services Computer InterfaceOSS Open Source SoftwarePC Personal ComputerPDA Personal Digital AssistantPDF Portable Document FormatPDF/A PDF ArchivePHP PHP: Hypertext Preprocessor
  • 155. SAGA 4.0 157PIN Personal identification numberPKCS Public Key Cryptography StandardsPKI Public Key InfrastructurePKIX IETF Working Group "Public-Key Infrastructure (X.509)"PNG Portable Network GraphicsPOP Post Office ProtocolPSE Personal Security EnvironmentRDF Resource Description FrameworkRelax NG Regular Language Description for XML New GenerationREL Rights Expression LanguageRFC Request for CommentsRFP Request for ProposalsRFID Radio Frequency IdentificationRIPE RACE Integrity Primitives EvaluationRIPEMD RIPE (RACE Integrity Primitives Evaluation) Message DigestRMI Remote Method InvocationRMI-IIOP Remote Method Invocation over Internet Inter-ORB ProtocolRM-ODP Reference Model of Open Distributed ProcessingRSA Rivest, Shamir, Adleman Public Key EncryptionSAGA Standards and Architectures for eGovernment ApplicationsSAML Security Assertion Markup LanguageSC Service CenterSFA Simple Feature AccessSGML Standard Generalized Markup LanguageSHA Secure Hash AlgorithmSIGA Secure integration of eGovernment applicationsSigG German Digital Signature ActSigV Digital Signature OrdinanceSIP Session Initiation ProtocolSLA Service Level AgreementSMIL Synchronized Multimedia Integration LanguageS/MIME Secure Multipurpose Internet Mail ExtensionsSMS Short Message Service
  • 156. 158 SAGA 4.0SMTP Simple Mail Transfer ProtocolSOA Service Oriented ArchitectureSOAP Simple Object Access ProtocolSQL Structured Query LanguageSSH Secure ShellSSL Secure Sockets LayerTAN Transaction numberTAR Tape ArchiveTCP/IP Transmission Control Protocol / Internet ProtocolTESTA Trans-European Services for Telematics between AdministrationsTIFF Tagged Image File FormatTLS Transport Layer SecurityTMS Travel Management SystemTriple-DES Triple Data Encryption StandardUDDI Universal Description, Discovery and IntegrationUDP User Datagram ProtocolUML Unified Modeling LanguageUN/CEFACT United Nations Centre for Trade Facilitation and Electronic BusinessURL Uniform Resource LocatorUTF Unicode Transformation FormatVDE Association for Electrical, Electronic and Information TechnologiesVLAN Virtual Local Area NetworkVM Virtual MachineVoIP Voice over IP (IP telephony)V-PKI Administration Public Key Infrastructure (Administration PKI)VPN Virtual Private NetworkW3C World Wide Web ConsortiumWAP Wireless Application ProtocolWCAG Web Content Accessibility GuidelinesWCS Web Coverage ServiceWebDAV WWW Distributed Authoring and VersioningWFS Web Feature ServiceWML Wireless Markup Language
  • 157. SAGA 4.0 159WMS Web Map ServiceWMV Windows Media VideoWS Web ServiceWS-BPEL Web Services Business Process Execution LanguageWSDL Web Services Description LanguageWS-I Web Service Interoperability OrganizationWS-Security Web Services SecurityWWW World Wide WebXadES XML Advanced Electronic SignaturesXHTML Extensible Hypertext Markup LanguageX-KISS XML Key Information Service SpecificationXKMS XML Key Management SpecificationX-KRSS XML Key Registration Service SpecificationXMI XML Metadata InterchangeXML Extensible Markup LanguageXÖV XML-based technical standards for electronic data exchange within and with the public administration.XSD Extensible Markup Language Schema DefinitionXSL Extensible Stylesheet LanguageXSLT Extensible Stylesheet Language Transformations