Administration on the Net. An ABC Guide to E-Government in Austria

Transcription

1 Administration on the Net An ABC Guide to E-Government in Austria June 2004

2 Imprint: Publisher: Federal Chancellery, ICT Strategy Unit A-1014 Vienna, Ballhausplatz 2 Tel.: ++43/1/53115/6152 Fax: ++43/1/ office@cio.gv.at Reproduction of extracts permitted. Person responsible for content: Prof. Dr Reinhard Posch Editor: Dr Birgit Wilder Layout: ICT Strategy Unit of the Federal Government 2

3 Contents INTRODUCTION... 7 WHAT IS E-GOVERNMENT?... 7 E-GOVERNMENT IN THE AUSTRIAN ADMINISTRATION... 7 FUNDAMENTAL PRINCIPLES... 9 THE BASIC ELEMENTS HOW HAS THE ADMINISTRATION CHANGED? CHALLENGES FRAMEWORK CONDITIONS VISION OBJECTIVES PRINCIPLES COOPERATIVE PROCESSES ORGANISATION ICT BOARD E-GOVERNMENT INITIATIVE E-Government Platform E-Cooperation Board E-Government Roadmap ICT Strategy Unit Private-Sector Platform LEGAL BASIS THE E-GOVERNMENT ACT MODULES SUBSTRATEGIES Part 1 Online Procedures Part 2 Internal Administrative Procedures and Methods CONCEPTS Citizen Card Electronic Delivery Electronic Confirmation of Payment POLICIES Internet Policy Policy GUIDELINES Certificates Server Certificates in Administration Form Style Guide WAI Guidelines Procedural/Service Sectors PKI in Administration...58 The gv.at Domain BASIC SERVICES Online Application Modules Inter-Administrative Directory Service Standard Submission Model Application Administrative Portal help.gv INTER-ADMINISTRATIVE COOPERATION PORTAL GROUP

4 4 PROJECT MODEL COMMUNITIES CITIZEN CARD COMMUNITY HITZENDORF WORKING GROUPS INFRASTRUCTURE ELECTRONIC RECORD SYSTEM (ERS) E-LAW BROADBAND ACCESS TO THE INTERNET REGISTERS Standard Document Register SourcePIN Register Supplementary Register Documentation Register Register of Addresses Building and Homes Register Central Register of Residents Central Register of Associations IT SECURITY AND DATA PROTECTION SOURCEPIN SECTOR-SPECIFIC PERSONAL IDENTIFIER CITIZEN CARD AS SECURITY INFRASTRUCTURE IDENTITY LINK ELECTRONIC SIGNATURE Secure Signature Administrative Signature Official Signature ELECTRONIC AUTHORITY IT SECURITY HANDBOOK VIRTUAL PRIVATE NETWORKS (VPNS) SECURITY LEVELS SECURITY CLASSES IN THE PORTAL GROUP X.509 CERTIFICATE ENHANCEMENT INTERNATIONAL STANDARDS SPECIFICATIONS PERSONAL DATA SECURITY LAYER STANDARD DISPLAY FORMAT SL MOA ID MOA SP AND SS IDENTITY LINK EPS 2 E-PAYMENT STANDARD ELECTRONIC DELIVERY Communication Structures Delivery Directory Schema LDAP gv.at X.509 CERTIFICATE ENHANCEMENT OID OF THE PUBLIC ADMINISTRATION METADATA E-GOVERNMENT OPEN SOURCE PROGRAMME AND TOOLS SECURITY CAPSULE TEST MAIL SERVICE FORM CONVERTER WLAN TEST INSTALLATION CRYPTOCONTAINER A-SIT INFOBOX SIGNATURE TOOL

5 MOA MC EPS SIGNATURE OF OFFICE DOCUMENTS DELIVERY ROBOT SSPIN COMPUTATION E-GOVERNMENT QUALITY MARK PUBLICATIONS INFORMATION PACKAGE E-GOVERNMENT BROCHURE NEWSLETTER WEBSITES SUMMARY

6 6

7 Introduction Modern Information and Communication Technologies (ICT) allow the public administration to provide new electronic services on the Internet. Thanks to the technology, these new e- Government services can respond more effectively to the needs of users. The services can be accessed easily on the Internet. It is no longer necessary to make one s way to an office. The services offered are available electronically, irrespective of time or place. It is important to bear in mind that administrative matters can, but need not, be dealt with on the Internet. E-government is offered as an alternative, but it is not compulsory. The traditional office continues to be open to all those who prefer personal contact with the authorities or who are not yet familiar with the new technologies. However, e-government is intended to offer advantages to those people too, since, even in the case of a conventional visit to an office, administrative matters can be dealt with more quickly as a result of e-government. What Is E-Government? The provision of electronic administrative services offers users convenient access to public administration. 1 For authorities that make use of information and communication technologies (ICT) in order to be able to provide electronic services, this will entail large-scale internal adjustments to their organisation. Some processes will have to be revised and operations will have to be adapted to meet the new requirements. 2. Internal work will be increasingly automated. Administrative staff will therefore require the knowledge and skills needed to be able to operate the technology used. E-government consists of all of these elements. At EU level, e-government is defined as: The use of information and communication technologies in public administration combined with organisational change and new skills in order to improve public services and democratic processes and strengthen support to public policies. 3 E-Government in the Austrian Administration Since the Federal Government revised its IT strategy in 2000, much progress has made in the development of e-government. A number of administrative procedures can already be conducted entirely on the Internet. Sustainability, security and data protection are of fundamental importance. Durable e-government can be realised successfully only on the basis of a comprehensive strategic concept. The Austrian e-government strategy defines fundamental concepts, basic components and standards that serve as guidelines for the implementation of electronic services and the creation of an infrastructure. 1 The user end is often called the front end. 2 This allows the authorities to act in a more transparent manner. 3 Communication from the Commission to the Council, the European Parliament, the European Economic and Social Committee and the Committee of the Regions: The Role of egovernment for Europe s Future COM (2003) 567 final of 26 September 2003; Commission of the European Communities, 7

8 The e-government strategy is to be regarded as a blueprint and guideline for continuous structuring and development and permanent adaptation to new technologies (change management). The proposed sub-strategies, policies, measures and initiatives form part of the structural guidelines on the minimum standards and conditions to be met and combine to create a homogenous whole. The basic principles and considerations underlying an integrated overall architecture are embedded in that strategy. Catchwords such as citizen card, electronic signature, register, portal group, electronic delivery, security or electronic payment indicate the broad spectrum of components forming e-government in Austria. E-Government Act Standards Electronic Service of Documents Electronic Signature Citizen Card Change Management Portal Group Modules for Online- Applications Sector-Specific Personal Identifier (sspin) E-Gov. Strategy Part I: Online-Procedures Policies, , Security, etc. E-Gov. Strategy Part II: Electronic Payment Administrative Methods/Procedures Despite initial success in comparison to other international projects, the establishment of an inter-administrative system of e-government can by no means be regarded as complete. Certainly, the existing components and concepts have a wide scope; however, new components and entire areas, such as the electronic participation of citizens, are constantly being added. The continuous evolution of e-government must remain straightforward and transparent. This is necessary not only for the staff involved in the administration and the private sector but also for all users. The purpose of this Guide to E-Government is to respond to the desire of the regions, municipalities and local communities to summarise clearly the most important components of Austrian e-government in a single document. The Guide to E-Government is intended to provide all those interested with an overview of the developments to date. It is structured in such a way as to allow the reader to study each of the various subject areas in greater depth, according to his or her particular interests. Therefore, general matters such as the basis, legal requirements and organisational framework are explained in the first part of the document. The following chapters deal with the various individual modules forming the basis for e-government. The final chapters give details on the specifications and existing tools. Finally, there is a brief explanation of the quality assurance provided by the Austrian e-government quality mark. A list of publications and useful links completes the document. The final remarks are set out in a brief summary. 8

9 Fundamental Principles 9

10 Neither a person s location nor the fact that he or she belongs to a group with particular needs may act as an obstacle to the use of e-government services. Wherever possible, citizens should also be able to use familiar technology, such as mobile phones. The widest possible proximity to citizens can be guaranteed only by access for all without discrimination and without the need for special skills. This includes access via an intermediary for all those who are unwilling or unable to use a computer themselves. Electronic services provided by the public administration should be attractive to all users. The need to be accessible to all means a simple design is required. The primary aim in structuring processes must therefore be to maximise convenience. Convenient access increases the willingness of users to make increased use of electronic services. The aim of an efficient service for citizens must be the widespread availability of electronic services, including payment and delivery, so that all local obstacles to access can be removed. In addition to standard interfaces, a standard layout for forms is a basic precondition for the elimination of user inhibitions. Increasing efficiency is one of the fundamental objectives of e-government. In addition to the creation of an infrastructure, implementation is therefore focused on integration of processes which are used particularly often. This applies, in particular, to processes in sectors such as finance, justice or business. The electronic record system (ERS) provides, together with the portals, the basis for the electronic handling of procedures tailored to transactions. The greater the willingness to make intensive use of electronic administrative services, the greater the chances are that the administrative systems will be able to function effectively. The administrative authorities decide, on the basis of an evaluation of cost effectiveness whether a process has to be automated via electronic record or by way of an integrated application. With the exception of speed, the decision will not affect citizens as the service will be available electronically, even if the subsequent procedures are carried out manually in the conventional manner. A successful system of e-government is based on three fundamental pillars: 1. A clear legal framework which can be easily understood and can thus rapidly become part of public awareness Secure and thus sustainable systems and services as a precondition for nationwide implementation and increase of confidence of citizens in electronic administrative services. 3. The use of sustainable technology on the basis of open standards and defined interfaces in order to ensure continuous adaptation to new technology. In the past, help.gv has successfully established itself as a central point of access to public services. Its development into a portal for transactions should lead to an optimum access and provision of services for citizens. Sustainability can be achieved only by implementing international standards and open interfaces the use of which is not restricted to the products of a certain manufacturer. Such 4 A clear statutory framework is an essential factor with respect to the timetable for implementation. 10

11 implementation lays the foundation for the interaction of different systems and organisational structures. The use of flexible interfaces and standards which are not reserved only to individual providers is also consistent with Austria s SME-orientated economic structure and can therefore contribute to improving Austria s attractiveness as a business location. The Basic Elements The basic elements of e-government can be divided into three categories: 1. Elements of organisational implementation help.gv ERS SAP Finanz Online Electronic administration of E-learning portals justice E-business portals E-voting Opinion polls 2. Elements of technical coordination Citizen card Secure electronic payment Delivery Form Style Guide Portal group Modules Joint e-government 3. Structural measures Knowledge management Instruments for assistance Human resources Qualification Catalogue of services Funding How Has the Administration Changed? In the past, differently structured procedures were a typical feature of the administration. The increasing use of information and communication technologies has led to heightened cooperation beyond administrative boundaries. Interoperability, transparency, proximity to citizens and customer orientation benefit as a result. The new approach is based on a common, service-orientated infrastructure, open interfaces, dynamic applications, modularity and change management. This approach, accompanied by the technical and organisational integration of administrative processes, guarantees a durable, flexible and interactive administrative system. 5 The system of voluntary coordination is being replaced by compulsory cooperation between authorities at different levels. The technological and organisational change in public administration entails major changes for its staff. The constant development of new processes and new software such as the electronic records system (ERS) demand the continuous adaptation of their technical, organisational and social competence. The need to deal speedily with s, requests for information and other matters of concern to administrative customers therefore make it 5 The part of e-government conducted internally by the administration is often called the back office. 11

12 necessary to provide public officials with constant further training and to ensure tight internal organisation. Another major challenge is the new nature of the contact with citizens. The focus must now be on service and customers. The expectation that acts will be dealt with in a speedy and relatively informal manner appropriate to communication by is a fundamental change in the working environment of the public authorities, which also entails new requirements on the conventional decision-making structures (competence to act) in the administration. The technological progress also makes telework possible. Framework conditions satisfactory for all concerned must be established for this form of working. Challenges Electronic services provided by the public administration served in recent years in many areas as pioneers for other authorities. Finanz Online, the online administration portal help.gv, the Federal Government s legal information system (Rechtsinformationssystem, RIS ), the Register of Companies and Land Registry are just some examples that were copied in many other countries. Although successful in some respects, the adoption in 2000 of the EU initiative eeurope 2002 quickly showed that the Austrian administration s then fragmented IT system was unsuitable for a sustainable development of e-government in Austria. The loose cooperation between the administrative authorities in the area of IT had to be replaced by compulsory cooperation. At political level, the objectives were set in a government programme. All administrative services were to be available to citizens and the private sector in electronic form also by In spring 2002, at the same time as the EU projects, the first steps towards the creation of a comprehensive system of e-government were taken with the reorientation of the Federal Government s IT strategy. At organisational level, the new strategic direction was expressed by the setting up of the ICT Board 6 and the appointment of the Federal Chief Information Officer by the Federal Government. The Federal Government s ICT Strategy Unit was established to provide support and its staff was largely provided by the Federal Ministries as a sign of the new willingness to cooperate. With the establishment of the ICT Board, a body was set up that was able to develop clear requirements at Federal level for the creation of a uniform system of e-government. However, at the same time, it was clear that e-government cannot be limited by the boundaries of the Federal Government, provinces and local authorities. Open and constructive cooperation involving all actors at all levels was therefore essential. In order to guarantee their success, the necessary concepts and strategies were developed transparently in consultation with the provinces, local authorities and municipalities. Although Austria had set an example for the rest of the world in many areas of online administration, those individual services were no longer sufficient to attain the leading position in performance ahead of the rest of the EU (benchmarking). E-government was therefore declared to be a top-level priority and the agenda were transferred directly to the Federal Chancellery. In May 2003, the Federal Government introduced the e-government Offensive, which sets clear priorities for a speedy development of electronic administration in Austria. 6 Information and communication technologies 12

13 The aim of the Offensive was quickly to achieve a leading position in the European Union in the field of e-government. The basis for achieving that aim is comprehensive support for and cooperation with the political decision makers of the Federal Government, the provinces, local authorities, municipalities, social insurance bodies and the private sector. Therefore, an E-Government Platform was set up under the direction of the Federal Chancellor, which makes the necessary institutional cooperation possible. The proposed projects are summarised in a catalogue of services that lays down a specific roadmap for the implementation of e- government in Austria by the end of Austria stands out from the other Member States of the EU on account of its comprehensive approach to developing e-government. All components and solutions are to be implemented in all areas of administration throughout the country. The technical solutions adopted such as the security layer, electronic service delivery, electronic payment and electronic signatures are based on internationally accepted standards and are independent of a particular brand of technology. Implementation throughout the EU would therefore make sense. Austria serves as a role model for the use of the citizen card and electronic signatures. Austria s leading role in the area of identity management should be consolidated by increased involvement at the European level. Electronic administration is not intended to serve citizens only. Many e-government applications are aimed at businesses. Whilst, for many businesses, it is nothing new to deal with administrative matters online, since, even in the past, IT solutions were used to carry out transactions with authorities. Nevertheless, the introduction of the e-government components will have a particular impact on the private sector. First, businesses must adapt to these new technologies and, secondly, they can use the new components such as, for example, the citizen card or sector-specific personal identifiers (sspins) even for electronic business transactions with business partners and customers. The E-Government Offensive created a Private-Sector Platform designed to serve businesses as a forum for all active exchanges of information and experiences with the public administration. The private-sector platform also provides an opportunity to cooperate in projects. In order to smooth the way for electronic administration, it is necessary to make, in addition to organisational changes, legal adjustments. The provisions applying to date, which were designed to govern the traditional paper office, must be extended to take account of electronic administration. E-government elements such as the citizen card, electronic forms, electronic signature, electronic payment and electronic service delivery have been made possible by the E-Government Act (E-Government Gesetz). A high-quality infrastructure is necessary in order to guarantee a quality-orientated system of e-government. The new information and communication technologies can be used only if there is effective access to the Internet. In order to promote broadband access, users will therefore be able in 2004 to offset the costs of their broad band access against tax as special expenditure. In addition, the provision of Internet access in public buildings by way of public terminals (public Internet access points, PIAP) or wireless networks (WLAN) should contribute to the development of the infrastructure. The society we live in today is constantly changing and there is no doubt that information and communication technologies play an important role in that change. In the knowledge society, information and knowledge are becoming ever more important for success in life. The use of electronic media and technology in the administration requires not only that administrative staff have the necessary skills. Citizens too must be able to cope with the new services offered. Easy operation, uniform structure and logical processes should make it easy to use the services offered by e-government. 13

14 The advances in digital administration and the opportunities for electronic participation must not lead to a two-class society. At the same time, the expression of opinion must not mean that people s lives become transparent. This double challenge requires particular caution in the area of e-governance. All people wishing to use the services offered by electronic administration should have the opportunity to do so, regardless of whether they do so at home on their own PC or from a public terminal. As an alternative to the conventional visit to the public offices, e-government services must be straightforward and easily accessible. Systems providing assistance should facilitate adjustment and support users of electronic services in carrying out the various steps with advice and practical guidance. Framework Conditions The public expects a service-orientated performance from a modern administration. A public administration that does not use modern information and communication technologies has become inconceivable. New quality standards such as efficiency, speed, service orientation, flexibility and security are among the features that modern public administration pursue. The medium of the Internet provides the administration with new means of internal communication. Whilst in the past, only certain steps of an administrative procedure could be carried out electronically, entire transactions can now be performed. In the future, the global use of the electronic signature will guarantee the necessary level of information security and cryptography will ensure data protection. The implementation of this technology and its application must become a matter of course. Together with the developments in technology, the self-definition of administration has changed. The picture of a fragmented administration has been replaced by the one-stop principle established at European level. Citizens should no longer be burdened by the complexity of the administrative apparatus and of competence issues. It must be possible to obtain a service from a central point, irrespective of the processes that the administration must carry out in order to deal with the matter. Service must therefore become a synonym of ease, convenience and speedy completion. Vision Interoperable system architectures, secure automated transactions, technology-neutral developments, structured and standardised process models, cost awareness, integration of existing methods and procedures, network and information security and change management are the characteristic features of a modern and efficient administration. The outmoded fragmented administrative structure is replaced by the model of cooperative administration. E-government in the information age gives rise to a new kind of relationship between citizens and the authorities. New means of communication and technologies offer users free and open access to the virtual world of public institutions. The public administration is shedding its bureaucratic character and is transforming into an efficient, service-orientated provider of services. Applicants are becoming customers enjoying the best service possible. User-friendly procedures, transparent processes, quality-orientated service and proximity to citizens are the essential features of modern administration. Applications of citizens and business are to be conducted interactively by way of an uncomplicated and time-saving dialogue. Administrative decisions and documents are delivered electronically. The electronic signature 14

15 and encryption mechanisms ensure data security, data integrity and data protection. E-government gives citizens the chance to participate directly in opinion-forming and decision-making processes. Public discussion forums and Internet chat rooms can be used to intensify the dialogue between citizens and the bodies responsible for political decisionmaking. In the future, it will, in the virtual world, be easier to involve citizens in advance in the legislative process. Objectives Smoothly functioning, partially automated procedures require that the necessary processes be conceived jointly. Current transactional processes must be analysed and where necessary remodelled. Close cooperation between the authorities at all levels leads not only to increases in quality but also to valuable synergies. The joint use of infrastructures, agreed distribution of the workload and costs arising from the structuring of processes and coordinated proceeding in developing modules for technical procedures help to avoid duplication and partial solutions. The new cooperative approach has already been adopted in large sections of the administration beyond the area of electronic data processing. In order to become a consolidated culture of administration, this approach must be supported by administrative staff. Staff must therefore have the opportunity to become involved from the very outset in the restructuring of procedural processes and the introduction of new technologies. In the long term, we will continuously be confronted with new technical concepts. In order to ensure that development in e-government does not remain static, it must be possible to make appropriate use of these concepts. Strategic considerations must from the very beginning take account of change management in order to remain forward looking. Particularly in the field of security, not only new developments but also additional and stricter requirements are to be anticipated. Adaptable technologies require continuous formation and training of administrative staff. The management and transfer of knowledge are central components of a modern system of administration. The future will, above all, bring a broader range of applications making it possible to participate actively in the administrative process. In order to prepare for this challenge, the skills of administrative staff must be generally increased in the field of IT and e- government. Plans for the outsourcing of operative tasks and increased involvement in strategy and structural changes must go hand in hand with a marked increase in social and technical skills. Principles The Austrian e-government strategy is based on some important principles: Proximity to citizens. The administration must be at the service of citizens and not vice versa. Online services must be easy to locate. Convenience through efficiency. Citizens expect greater convenience from online procedures: No need to go to an office, no restrictive office hours, no waiting, no being sent from one authority to the next, but instead straightforward processes, 15

16 intelligent forms which are easier to complete, responsible handling of data and speedy disposal. In order to meet these expectations, public administrations must optimise processes by automating them and making use of modelling Confidence and security. Electronic contact with the public administrations must be just as secure as the classic visit to an office. In the electronic world, the identification and authentication of persons is ensured by sector-specific personal identifiers (sspins) and the electronic signature. The secure exchange of information and transfer of data is guaranteed by defined security standards. Transparency. The success of technical solutions and their acceptance is dependant on the involvement of all relevant groups in their development. It is particularly important that the private sector and the administration cooperate in advance so that implementation can be endorsed by all. Transparent processes provide the basis for cooperation. Accessibility. Services provided by the public authorities must be available to all without discrimination. This also applies to the new electronic administration. E- government is to be available to all social classes and groups. Technical and social barriers must be prevented. The adoption of the Web Accessibility Guidelines 7 is an attempt to counteract the risk of exclusion. Greater availability of public terminals should in future facilitate the access to e-government in Austria. Whether it be the Federal Government, the provinces, municipalities or local authorities, all are called upon to make an increased effort to achieve this aim. Usability. The range of electronic services offered must be structured in an easily comprehensible, clear and straightforward manner. A standard layout for forms and portal structure arranged according to personal circumstances facilitates clarity, navigation and usability. Data protection. Citizens place a high degree of confidence in the Austrian administration with regard to data protection. The use of new technologies in the administration allows that confidence to be extended to electronic administrative systems also. The use of the electronic signature for the purpose of authenticating persons and of encryption mechanisms guarantees that the currently high standard of data protection is maintained. Sector-specific personal identifiers, the mechanism developed specially for the purpose of identification conforming to data protection standards, ensures that, as has been the case to date, only authorised persons within the administration can obtain access to personal data. Cooperation. Smoothly running e-government can be achieved only by comprehensive cooperation between all levels of the administration. Existing applications and infrastructures must be used jointly in order to achieve the desired aim of organisational, financial and administrative efficiency. Cooperation between public bodies is based on the fundamental approach of making interfaces openly accessible and basic functions available free of charge. Sustainability. The modular structure facilitates change management, which permits continuous further development. Open e-government contributes to improving competitiveness and thus to safeguarding Austria s position as a location for business. The strategic coordination of the ICT sector within the administration is of fundamental 7 Guidelines of the World Wide Web Organisation, which are intended to prevent discrimination in access to web content, 16

17 importance in that regard. Interoperability. Systems must be able to communicate with each other. Therefore, e-government conventions designed to govern implementation are being drawn up on the basis of internationally accepted standards and open interfaces. Technological neutrality. Information and communication technologies are being developed rapidly. E-government solutions must therefore be open to new technologies. No particular technology has to be preferred and dependency on monopolies must be avoided. The use of information and communication technologies makes it possible to organise public administration in accordance with these principles. The range of electronic services offered represents an alternative to the traditional office that is available 24 hours a day. Citizens can choose freely between the two forms of dealing with administrative procedures. Open e- government, accessible to all members of the public, counteracts the risks of digital exclusion. Cooperative Processes Since the ICT Board 8 took up its activities, great importance has been placed on cooperation between the Federal Government, the provinces, municipalities and local authorities. The publication of decisions on the website ensures compliance with the principle of transparency. The reference server 9 set up by the provinces acts as a platform for communication between all levels of administration on which proposals for working methods and concepts and contributions to discussion, as well as conventions concluded between the Federal Government and the provinces, are published. Administrative tasks are for the most part performed by the provinces (Bezirkshauptmannschaften (regional councils)), municipalities (Magistraten (municipal corporations)) and local authorities. Without basic coordination, the highly federal nature of the Austrian state would, in the long term, lead to differing approaches. Citizens and the private sector would, however, have little understanding for such differences. Joint and coordinated action is therefore a principle ensuring the beneficial implementation of e- government. In order to profit from synergies, the IT activities at both provincial and Federal level 10 are coordinated in various working groups and priorities are set jointly. Working groups focusing on specific needs act in concert with the ICT board to support the coordinating activities. This means that concepts and projects are agreed before decisions valid across administrations at all levels are adopted. This means that differences of opinion at the expert level can be avoided. 8 See Chapter Organisation See Chapter Inter-Administrative Cooperation 17

18 18

19 Organisation 19

20 Since 2003, many services of public administrations are available online. All public services capable of being dealt with on the Internet are to be available electronically by In order to implement these objectives, a structured approach is required. Account has been taken of the increasing participation of actors and administrative levels in the development process by consolidating the organisational structures in a way that allows consensual proceeding. ICT Board The ICT Board was set up by order of the Council of Ministers in June 2001 on the basis of the recommendations made by the Task Force E-Austria in eeurope. The establishment of the ICT Board laid the foundations for comprehensive coordination of the ICT planning activities of the Federal Government and structured cooperation with the provinces, municipalities and local authorities. Federal Chancellor Vice Chancellor CIO Federal Government ICT BOARD CIO Ministry CIO Ministry CIO Ministry CIO Ministry CIO CIO Ministry Ministry CIO Ministry CIO Ministry CIO Ministry CIO Ministry CIO CIO Ministry Ministry ICT Strategy Unit of the Federal Government The body is composed of the Chief Information Officers of the Federal Ministries and their deputies. The Board members were nominated by the various Federal Ministries. They are responsible for providing information and carrying out agreed IT activities within each ministry. The ICT Board is entrusted with the coordination of information and communication technologies at federal level and thus with the organisational implementation of e- government. It deals with the horizontal aspects of information and communication technologies and is responsible for the coordination of projects with the provinces, local authorities and municipalities. The ICT Board receives legal advice from the Constitutional Service of the Federal Chancellery. The Federal Chief Information Officer, appointed by the Federal Government, is responsible for the management of the ICT Board. He regularly reports to the Chancellor and Vice- Chancellor on ongoing activities. Ensuring that projects are carried out in accordance with strategy is primarily the responsibility of the Federal Ministries, which must ensure that the applications function. In implementing their projects, the ministries are bound by the agreements concluded within the ICT Board. The strategies agreed by the ICT Board are drawn up under the following procedure The ICT Strategy Unit draws up strategy proposals, which are then submitted to the ICT

21 Board and to the provinces, municipalities and local authorities. 2. Where necessary, working groups are set up where representatives of Federal Ministries, provinces, municipalities and local authorities can participate. 3. Information is exchanged within and between the working groups by means of reference.e-government.gv.at, an inter-administrative communication platform that is continuously updated. 4. The ICT Board and the bodies of the provinces, municipalities and local authorities adopt the strategy proposals. Since the ICT Board was set up, a large number of projects have been implemented. However, the complexity of the tasks to be performed has increased markedly. Whilst the ICT Board s field of activity is limited to the federal level, comprehensive e-government does not stop at administrative boundaries. Not only public bodies must be involved in the implementation but, in principle, all organisations and institutions that exchange information with the administration, are instructed by the administration to perform services or offer services to the administration. Even private-sector bodies offering e-government solutions must be included so that they can satisfy the strategic requirements. E-Government Initiative 2003 Information and communication technologies do not represent new territory for the public administration. Many electronic services provided by the Austrian administration served as role models in the European Union. Among those services were the Federal Government s legal information system 11 and Finanz Aministrative Portal help.gv 12 has had pioneer status for some time and was awarded the European E-Government Prize in July However, in the past, Austria despite good basic conditions lay behind in the benchmarking of e-government services in the European Union. The Federal Government s E- Government Offensive of June 2003 represented an important step in reversing the trend. The aim of the Offensive was to lead Austria to regain one of the top five places at the European field by mid Some initial success has already been achieved as a result of joint efforts. The short-term goal was achieved with the fourth ranking in the most recent EU benchmarking in This rapidly achieved success can be attributed not least to the important preparatory work carried out since the Federal ICT Strategy was revised in The principles underlying those activities are quality before quantity, promotion of open structures and sustainability. Security, data protection and accessibility for all classes of society are preferred to solutions which can be implemented quickly but are short lived. Despite the initial success, it is now necessary to consolidate what has been achieved and to communicate to a greater extent within and outside the public authorities. Efforts must continue to be made in order to maintain the leading position in European e-government

22 E-Government Platform The setting up in 2003 of the E-Government Platform, which acts under the chairmanship of the Federal Chancellor, provided an important political impetus for the cooperative development of e-government in Austria was provided in 2003 by. The E-Government Platform lays down the objectives of e-government activities, draws up the e-government roadmap, ensures the overall coordination of implementation and monitors progress. A Federal Executive Secretary was specially appointed by the Federal Government to carry out the task of coordination. The structured cooperation of all bodies working in the field of e-government is intended to lead quickly to efficient and customer-orientated electronic administration. E-Government Platform Chairman: Federal Chancellor Privat- Sector Plattform E-Cooperation Board Chairman: Executive Secretary E-Government E-Government Working Groups of the Provinces Federal Government ICT-Board Director: Federal CIO Provinces Municipali ties ICT Local Authorities Local Authorities Expert IT Committee of the Municipalities The Platform is composed of the Vice-Chancellor, the Minister for Justice, the Minister for Home Affairs, the Minister for Finance, the Secretary for the Arts and Media, the trio of chairmen of the Provincial First Ministers Conference, the Presidents of the municipal and local authorities associations, the chief association of social insurance organisations, the Austrian Chamber of Commerce, the Main Association of Austrian Social Security Institutions, the Federal CIO in his capacity as Chairman of the ICT Board, the directors of the legal and technical e-government working groups of the provinces, external experts and the Federal Executive Secretary for E-Government. The E-Government Platform has already adopted a roadmap containing proposals to be carried out gradually by the end of Many of the projects concentrate on the creation of basic components which are essential to effective implementation of e-government services at all administrative levels. E-Cooperation Board The E-Cooperation Board supports the E-Government Platform in achieving its objectives. The E-Cooperation Board is composed of all ministries, provinces, association of local authorities, association of municipalities and interest groups. The Board is headed by the Executive Secretary for E-Government, who regularly reports to the Federal Chancellor and the Vice- Chancellor on the state of implementation and the progress made. The task of the E-Cooperation Board is to: 22

23 1. allocate responsibility for the preparation of implementation projects in the various fields of e-government;, 2. coordinate current work; 3. coordinate the implementation projects of the participating organisations (ICT Board, e-government working groups of the provinces and the public-administration bodies responsible for ICT); and 4. draw up an agreed proposal for a roadmap to be adopted by the E-Government Platform. In fulfilling its functions, the E-Cooperation Board is guided by the strategic objectives laid down by the E-Government Platform. E-Government Roadmap The E-government roadmap is a timetable for the implementation of all the administrative procedures which in future are to be offered to citizens in electronic form. A binding timetable has been established for all such procedures. The roadmap covers not only those procedures which, in future, it will be possible to conduct on the Internet but also implementation concepts necessary for basic services such as, for example, electronic payment or service of documents. The project period covered by the roadmap expires at the end of An institution has been appointed to be responsible for the planning and realisation of each project. All levels of the administration may participate in the various task forces. How is a roadmap drawn up? The projects which the E-Government Platform includes in the roadmap undergo several stages. A project proposal is made in the working group of the E-Cooperation Board and, if it is accepted by the members of the working group, is proposed to the E-Cooperation Board for inclusion in the roadmap. The E-Cooperation Board then makes a recommendation to the E- Government Platform that adopts the proposal as part of the roadmap. All proposals which are implemented in connection with the roadmap are summarised in the catalogue of services Service & Administration. 23

24 New common projects Existing common projects Individual projects Working sessions E-Cooperation Board Collection, Specification, Preparation Priorities, Flow of information Master pool of all project proposals Raw data Monitoring, Evaluation Coordination sessions E-Cooperation Board Timetable and resource planning Project tasks, Framework conditions E-Government Platform Roadmap Detailed data Implementation timetable Current version Draft concept, Detailed concept, Implementation Service catalogue administration Existing services A brief presentation is given for each project, containing information on the objectives, priorities, project management, project cooperation and the implementation date. Each individual project is implemented in various task groups, in which, depending on their area of interest and focus, representatives of the Federal Government, the provinces, local authorities, municipalities and industry cooperate. In future, information on all e-government projects will be stored in a project database. This will mean that up-to-date information on the state of the development of e-government in Austria is available at all times. ICT Strategy Unit E-Gov. Executive Secretary Federal CIO Executive Secretary E-Government Plattform E-Cooperation Board E-Government Strategy - Roadmap and Funding - Publicity/Marketing - Help.gv - Reporting/Quality assurance Private Sector/EU/Brussels CIO ICT-Board Technology ICT and E-Government ICT-Strategies International Issues - Technology (CWG Telecom) - Security (ENISA) - Signature (A9C) - OECD (ICCP) Technology-law coordination The ICT Strategy Unit 13 was set up in 2001 in the context of the reorientation of the Federal Government s ICT strategy. Its aim is to create, together with the Federal Ministries, municipalities and local authorities, maximum synergy in the implementation of e-government by way of efficient organisation and comprehensive cooperation. The Unit draws up concepts

25 and basic guidelines for the activities of the ICT Board and the E-Cooperation Board. The expertise of the Unit s staff is made available to the numerous task forces. The Unit is managed by the Federal Chief Information Officer, Prof. Dr. Posch, together with the Federal Executive Secretary for E-Government, Christian Rupp. Its areas of responsibility comprise project organisation, international affairs, technology, standards, public relations and administration. Private-Sector Platform Close contact with the private sector is maintained in order, first, to take account of the comments of that sector when developing concepts and, secondly, to glean information on strategic and technical matters. The information obtained guarantees that products and solutions are provided in accordance with strategy. Private-sector partners are no longer regarded as a threat but rather as providing an opportunity for all involved to focus their existing individual strengths and achieve long-lasting economic success. In order to promote dialogue between the administration and the private sector, the Private- Sector Platform was set up as part of the E-Government Offensive. It is a forum for information which is intended to provide businesses with an opportunity to obtain regular information on ongoing e-government activities and on the technical procedures and the standards followed. 25

26 26

27 Legal basis 27

28 Unlike other Member States of the European Union, Austria chose from the very outset to develop a nationwide, uniform e-government. Security and data protection are the top priorities of that development. The citizen card, electronic signature for authentication, sourcepin, sector-specific personal identifiers for identification and official stamp are just some of the basic elements used to implement e-government in Austria. The E-Government Act represents a major contribution to establishing a common strategy and to sustainable implementation. The E-Government Act The E-Government Act 14 entered into force on 1 March It serves as the legal basis for the instruments used to provide a system of e-government and for closer cooperation between all authorities providing e-government services. The new mechanisms, such as the electronic signature, sector-specific personal identifiers or electronic service of documents, may also be used by the private sector. The most important principles are: Freedom of choice between means of communication for submissions to the public administration; Security for the purpose of improving legal protection by creating appropriate technical means such as the citizen card; Unhindered access to information and services provided by the public administration for people with special needs by the end of 2007 by way of compliance with international standards governing web accessibility. The essential provisions are summarised in the following brief overview: Citizen card. Persons communicating with the administration can be uniquely identified and authenticated. Applications can be attributed to that person and he or she can be granted access to his or her personal data without any risk in terms of data protection. In order to ensure that an application is genuine and has not subsequently been forged by another person, it must be possible at all times to verify the authenticity of the application. Identity and authenticity are validated by using the citizen card and the electronic signature in accordance with the data-protection provisions. The citizen card can also be used for electronic business transactions (e-commerce) to increase the technical and legal security of Internet transactions. The citizen card is not dependant on a particular brand of technology. Regardless of whether the carrier medium used is a chip card, a mobile telephone or another technological means, it is essential that the citizen card contain an electronic signature and an identity link that contains the associated security data and functions, as well as any data on an authority to act as a representative which may have been granted. Identity link. The identity link is used to secure a unique link between the citizen card and its rightful holder. More specifically, the sourcepin Register Authority confirms by way of an electronic signature that a link has been established between the holder of the citizen card and his or her sourcepin for the purposes of unique identification. The identity link is entered on the citizen card

29 Authority to act as a representative. Individuals may authorise another person to submit applications on their behalf. In such cases, the sourcepin Register Authority enters on the citizen card of the representative the sourcepin of the person being represented and an indicator that authority has been granted, together with an indication of any temporal or material restriction. Authority functions can also be used by statutory representatives. SourcePIN. For the purposes of unique identification, all natural persons registered as resident in Austria are allocated a sourcepin, which is derived from the ZMR number 15 in heavily encrypted form. In the case of all other natural persons, the sourcepin is derived from their registration number in the Supplementary Register. The sourcepin of a natural person may be stored only in the citizen card. In the case of legal persons, the number of their entry in the Register of Company Names (Firmenbuch) or the Central Register of Associations (Zentrales Vereinsregister) or their registration number in the Supplementary Register is used as the sourcepin. Sector-specific personal identifiers. In order to guarantee data protection, the sourcepin of natural persons may not be stored by the authorities. The authorities may identify natural persons only by their sector-specific personal identifier (sspin). The sspins are derived from the relevant person s sourcepin. It must be irreversible and it must not be possible to reconvert it to obtain the original sourcepin. A sector-specific personal identifier is valid only for the sector of activity of the authority within which the initiated procedure falls. In order to generate a sector-specific personal identifier, the sourcepin is needed. The sourcepin may be used to generate the sspin only with the cooperation of the person concerned in the form of use of the citizen card. If the sourcepin is unknown, only the sourcepin Register Authority may generate an sspin without use of the citizen card by the person concerned, and it may do so only in certain circumstances. SourcePIN Register. The sourcepins required for the unique identification of persons are available from the sourcepin Register. The function of sourcepin Register Authority is performed by the Data Protection Commission. Supplementary Register. All natural persons who are not registered in Austria and legal persons who are not registered in the Register of Company Names or in the Central Register of Associations can be registered in supplementary registers. Administrative signature. In relation to citizen card functions, administrative signatures are to be treated by the public administration as equivalent to a secure signature until the end of It can therefore be used instead of a secure signature in all administrative procedures. Administrative signatures are signatures which provide adequate security for the purposes of validating identity and authorisation but do not necessarily satisfy all the requirements to be met by a secure signature and, in particular, are not necessarily based on a qualified certificate. The security and organisational requirements to be met by administrative signatures are laid down in the Administrative Signature Regulation (Federal Law Gazette No II, 159/2004). Standard Document Register. For the purposes of conducting procedures, citizens and businesses have until now been expected to provide proof of certain information, such as birth certificates, proof of nationality or entries in the Register of Company Names. In electronic administration, this is in many cases no longer necessary since electronic data already available in registers can be used. When a person registers 15 Unique number allocated to the citizen in the Central Register of Residents (the Zentrales Melderegister, hence ZMR number). 29

30 with it, the competent authority verifies the accuracy of the existing personal and nationality data by inspection of the relevant documents (standard documents) and then informs the Central Register of Residents that the information is accurate. Even where no registration procedure is being conducted, a person may request that the accuracy of the information be noted, provided he or she proves accuracy by presenting the relevant documents. Thus, certain information need no longer be presented by the person concerned but can, with the person s consent, be directly requested by the authority from the Central Register of Residents. Alternatively, the person may also present an electronically signed confirmation of registration issued by the Central Register of Residents. Businesses can use the documentation register provided for in 114(2) of the Federal Fiscal Code 16 for the purposes of providing electronic proof of fulfilment of the professional requirements for the exercise of an activity or of the nature of that activity. Official signature. Persons involved in administrative procedures must be able to rely on the genuine nature of documents from the authorities. The official signature is an electronic signature affixed by an authority to an administrative notice or document. This makes it easy to recognise electronic documents of the authorities. Not only can the genuine nature of the document be verified by means of the official signature. In the case of printed documents, the official signature also certifies the document automatically when it is converted back into its electronic form. Electronic service of documents. Documents issued by courts and administrative authorities can be served electronically via a delivery agent. Citizens who wish to have documents served electronically can register with a delivery agent using their citizen card (signature card or mobile telephone). They then receive administrative documents via that delivery agent. The agent notifies the recipient that a document is available for electronic collection. In order to protect the document against access by third parties, the document can be collected only after identification and authentication through use of the citizen card. Moreover, the document can be sent in encrypted form. Only the holder of the decryption key (private key) can then decrypt it. Service of the document is affected as soon as notification has been sent to the recipient of the document. The electronic signature provided by the recipient upon collection serves as a confirmation of service for the authority. Delivery services can also be provided by private-sector undertakings. Permission to act as a delivery agent is granted by administrative notice, provided that the defined requirements have been satisfied. Fees relief. During an initial introductory phase until the end of 2006, relief from fees is to be offered to encourage citizens and undertakings to make greater use of electronic administrative procedures. 16 In German: Bundesabgabenordnung (BAO). 30

31 Modules 31

32 Substrategies The rapid progress made in technology and the growing demands on public administration mean that long-term technological and organisational strategies must be developed. Administrative processes in widely varying areas, the use of new means of communication and various technologies must therefore be coordinated. The strategy adopted is explained in the two sub strategies Online Procedure and Internal Administrative Procedures and Methods. These deal with the existing framework conditions, objectives, the presentation of electronic administration to users, automated processing within the administration and the following basic components of online procedures: 1. Electronic forms which can be completed on the Internet and sent immediately; 2. Electronic signature with citizen card or administrative signature; 3. Electronic payment by way of online banking, credit card or mobile phone 4. Electronic administrative notices; 5. Management of the transition to paper 6. Electronic delivery; 7. Administrative portals belonging to the portal group which lead to online services of public administrations. In addition to these basic components, minimum standards applying to the exchange of information, secure transfer of data, electronic records and data formats are set out. 32

33 Part 1 Online Procedures Part 1 of the e-government strategies 17 considers all aspects which must be taken into account in introducing users to electronic administration: E-government users are directed to the services offered via portals. Portals can be divided into various categories according to their objective and effect. The security requirements of portals depend on the services offered. The greater the degree of data protection required and binding nature of the transaction effected, the more security measures must be taken. All the portals offering e-government services or dealing with electronic transactions must be set up in accordance with the strategic requirements and must integrate the basic components. A clear distinction between function and accountability makes it possible to adopt a flexible approach of competing portals. Administrative services may be provided either by the administration itself or by the private sector. Clear provisions have been adopted in relation to outsourcing to a private-sector provider, which govern access and the handling of transactions. There is a clear division of responsibility between the four main elements involved in an online transaction, that is to say, user, portal, gateway, application. Users can approach the administration electronically. In principle, the internal administrative handling of a procedure remains independent of the fact that the procedure is available to the user electronically. The administration may make an internal decision, according to economic efficiency, whether to process files manually, with electronic support or by way of entirely electronic mechanisms. However, given the widespread introduction of the Electronic Records System in the federal administration, this distinction between various forms of processing files is becoming less important. It is therefore all the more important that a standard form of making submissions be used, which is independent of the way in which the procedure was handled. The internal management of administrative processes must be based on a clear process model and be aimed at optimising performance and staff-related components. Citizens can choose between various different media for a dialogue with the administration. As a result of the approach of technological neutrality, no particular form of technology is given preference and all possibilities are open. Communication with the authorities by electronic means must be understood as an alternative to the conventional paper approach. It remains possible to approach authorities directly in person. Until now, administrative procedures could be accessed electronically with a user ID and a password. This is replaced by the use of the electronic signature and the identity link. Where there is an administrative network, the access rights and areas of responsibility of the administrative units must be defined in the root portals. Portals must communicate with one another in a secure, confidential and authenticated fashion. Certificates are used for this purpose

34 Security capsule Card interface XML Work station Application Standard elements Personal record Payment confirmation Security Layer SIGNATURE Identified Confidential (security level II) Web to XML iform Annexes E-Delivery Signed Printout Verifiable self-printed notices Trusted Viewer Certification services The handling of online procedures is based on standardised processes and defined interfaces and data formats. With respect to submissions to authorities, the use of web forms which can be automatically converted to XML documents is preferred. Intelligent forms for complex communications contain check mechanisms which improve the quality of the data entered. The submission converted into an XML document is signed electronically, in accordance with the XMLDSig standard, by the person making the submission. This allows identified communication in open networks without any loss of integrity and in line with authenticity requirements. XML structures are defined and disclosed in accordance with a uniform standard. The documents and formats used are published and can be used by public authorities or organisations instructed by them for administrative applications without restriction. Notices and settlements issued by the public authorities are signed by them electronically (official signature) so that citizens can be assured that they are not fakes. The formats and presentation chosen must make it possible to reproduce the original electronic document even after it has been printed and it must still be possible to verify the electronic signature. The public authorities must implement an effective electronic delivery system, irrespective of whether or not the procedure was initiated electronically. Electronic delivery works across the various administrative areas and, at a later stage, may be extended to deliveries in the private sector. A standard format for transmission and a defined service protocol ensure that the public authority can effectively deliver documents to the delivery service. Service is an identified process. The receipt of a delivery is confirmed by the recipient by way of standardised proof of service. It must be possible to identify clearly the citizen who initiated an online procedure. In order to ensure data protection, recourse is had to a sector-specific personal identifier. This is a cryptographic code derived from personal and procedural data which cannot 34

35 be traced back to the person. The method of using sector-specific personal identifiers guarantees a high level of protection of the citizen s privacy while at the same time maintaining administrative transparency. The citizen card concept serves as the basis for the security infrastructure. This security system is available to all providers. The principal elements of the citizen card concept are the secure electronic signature, the qualified certificate and the identity link. Administrative procedures for which there is no statutory requirement for a secure signature can be settled using the administrative signature for a transitional period lasting until the end of Another important element of the security infrastructure is the security layer. This makes communication between the citizen card and the administrative procedure possible. As a result of the security layer, security technology is separated from the administrative applications, which is entirely in line with the strategic approach of open interfaces. It is irrelevant whether a signature card, mobile phone or other data carrier is used, because the security layer enables e-government to be independent of a particular form of technology. This represents a major contribution to interoperability. The use of electronic signatures makes it possible to retrace the processes of online procedure and thereby heightens the level of transparency and security. The use of electronic signatures also means that a proliferation of personal registers and networking between them can be avoided. 35

36 Part 2 Internal Administrative Procedures and Methods Part 2 of the e-government strategies 18 deals with the requirements which must be met by internal administrative processing (back office): Citizens expect electronic administration to save them time and provide speedy responses. The global introduction of the Electronic Record System (ERS) throughout the federal administration is therefore one of the basic elements of the e-government strategy. Using the ERS, it is possible for transactions to be effected in a fully automated manner and for public authorities to cooperate seamlessly. Standardised Internet forms submitted in XML format to authorities can be easily integrated into the internal processing procedure. Likewise, notifications can be directed automatically to the delivery service. At federal level, the ERS is being rolled out in a standard form in compliance with a defined gradual timetable. The basic concept was agreed with the provinces. The standard chosen was the international standard XML, which makes it possible to use electronic signatures and to carry out fully automated prior and subsequent processing. Administrative processes must be organised in the best possible way in order to ensure that they are handled efficiently and economically. The use of tools to modulate and optimise processes makes a detailed analysis of the course of a procedure possible. Existing working methods can be reorganised and improved on that basis. The communication infrastructure used for exchanging information and data must guarantee a smooth flow of communications within a public authority and between administrative units. Security, data integrity, automation and standardisation are of major importance in this respect. For that reason, several policies have been developed to define and standardise communication, data transfer, communication between security domains and all other necessary communication requirements and mechanisms. In doing so, account is at all times taken of the requested level of security by using widely accepted standards (e.g. XMLDSIG) and developing the confidentiality levels and security categories required for administrative procedures. Moreover, the equally important requirements of interoperability and compatibility are met through defined XML schemas. The electronic services offered by the public administration must be made accessible to everyone. Web forms, web content and online procedures must be provided taking account of the needs of socially-disadvantaged, older or disabled people. Straightforward usability and a clear structure improve the ability of all users to navigate through the available services. By implementing Level A of the WAI Guidelines, 19 web-content accessibility should be reached in the medium term. The E- Government Act provides for a transitional period ending on 31 st December In the long term, the highest level laid down by the guidelines should be implemented, in so far as is technically possible. Only those members of the administrative staff who actually conduct the procedure may access the electronic procedures. In order to keep a check on which officials should have access and to manage authentication information, directory services are used. The directories are intended to integrate the applications (ERS, budget and staff administration, etc.) and improve the quality of source data by serving as a central storage point. Moreover, the directories serve as the basis for further integration (portal group, telephone exchange, call centres, etc.) Guidelines of the World Wide Web Consortium (W3C), 36

37 Citizens must have confidence in electronic administration. Network and information security are therefore decisive factors in a security infrastructure involving all administrative units. Security domains and those responsible for them must be defined by the individual administrative units. In doing so, account must be taken of external access to the network. System users are authenticated by certificates. Communications are secured in accordance with international standards. 20 Qualified signature certificates for natural persons are administered by private-sector providers of certification services governed by statute. Certificates for public administration contain a special attribute known as an object identifier, 21 which identifies each authority and is based on international standards. All users can thus be sure that they are in fact communicating with the authority. For internal administrative purposes, staff cards will be issued, which the staff can use to carry out their duties. The staff cards will be fitted with the electronic signature and identification number of the official (official attribute). Administrative notices and other acts to be delivered on citizens or undertakings are electronically signed on dispatch from the server. The official signature allows the recipient to ascertain with certainty the identity of the authority and that the document delivered is genuine. A web application is available to users for the purpose of verifying the signature. A freely configurable module, 22 available free of charge, has been developed for the public authorities for the purpose of server-based creation and verification of signatures. The importance of IT security is growing constantly. Certain applications and systems must continue to function even in the event of power failures and disasters. The requirements which must be met by a critical infrastructure and framework conditions are laid down in a strategy for back-up systems. In order to combat the increasing attacks by viruses, a computer-virus warning and detection system has been created together with private-sector undertakings. That system is based on PKI security technology which is coordinated with European developments. The first phase of the virus warning and detection system is a service coordinated between the administration and Internet service providers which records and distributes qualified information in a secure form. The next phase will see the implementation of a system providing an automatic report including a statistical evaluation. This means that viruses which may be circulating at any given time can be pursued without any significant delay. 20 IPSEC and TLS are currently the prevailing standards. In the medium term, IPv6 is to be regarded as the method of choice. 21 Object identifier of the public administration, 22 Modules for online applications (MOA), 37

38 Concepts E-government is based on fundamental considerations relating to specific subjects which are summarised in concepts. Concepts outline the fundamental basis and explain the general procedure to be followed. Citizen Card Until now, for the purposes of making applications, citizens have, where necessary, identified themselves with an official photographic identity card. But what happens in electronic administrative procedures? As a means of identifying and authenticating persons, the citizen card is used. With this card, applications can be electronically signed and electronic letters from the authorities can be collected. The citizen card 23 itself is not dependent on a particular form of technology. Moreover, there is not just one single kind of citizen card. It is entirely up to the citizen to choose what technology to use in order to identify himself or herself electronically. In principle, any card which makes it possible to sign electronically in a secure form and to store data in free areas is suitable for use as a citizen card. In the same way as a passport, driving licence or identity card can be used in the paper world for identification purposes, the electronic world offers a variety of possibilities. Regardless of whether a chip card, mobile phone or USB equipment is used, the important point is that the medium satisfies certain security requirements essential for a citizen card. User - interface Citizen Signature Encryption Data-memory Security-Layer Hash-Value Citizen-card environment Application The Citizen-card model Source: A.Hollosi/ G.Karlinger, The Austrian Citizen Card. Introduction 24 The citizen card concept 25 is one of the foundations of Austrian e-government. It defines the functions necessary for secure electronic communication between citizens and administrative authorities: electronic signature, identification and data memory

39 The security requirements which must be met by a citizen card are defined in the citizen-card concept. The two most important requirements are the electronic signature and identification: Electronic signature The electronic signature is generated by a cryptographic procedure. Under the Signature Act (Signaturgesetz), 26 a secure electronic signature is to be used in administrative procedures requiring signature by one s own hand. The E-Government Act provides that, in relation to citizen card functions, the administrative signature is to be regarded as equivalent to the secure signature until the end of Identification It must be possible to establish with certainty a link between an electronic procedure and the person who initiated it. This ensures that non-authorised persons cannot access personal data. Until now, depending on the public authority concerned, reference numbers such as the social security number or tax number were used in administrative procedures for that purpose. In order to prevent confusion as to the person concerned in electronic procedures, the sourcepin is used to identify that person uniquely. The sourcepin is derived from the CRR number 27 by way of an encryption process and stored in the citizen card in an electronically signed form. The sourcepin can therefore be controlled only by the rightful holder of the citizen card. For data-protection reasons, the sourcepin of natural persons may not be stored directly in applications. In administrative procedures, the person must be identified using the sector-specific personal identifier, which is derived from the sourcepin and the sector code. The application of these two encryption processes (encryption of the CRR number in the sourcepin and derivation of the sector-specific personal identifier from the sourcepin) guarantees a high level of data protection and rules out the risk of transparent people. The citizen-card concept not only lays down particular security requirements but is also aimed at ensuring variety and permits the use of a diverse range of forms of citizen cards. At present, a number of entities offer citizen cards (e.g. the membership card of the Österreichische Computergesellschaft (the Austrian Computer Society)). Widespread availability of the citizen card is to be expected in 2004 with the issue of the new bancomat (ATM) cards, which can also be used as a citizen card. However, in the spirit of European mobility, even citizen cards issued in the other Member States of the EU can be used, provided they are equipped with an identity link or are capable of being so equipped. 28 At present, citizen cards are issued in, for example, Italy, Estonia and Finland. It is already possible today to integrate the Italian and Finnish cards into Austrian e-government as soon as this service is opened to the public. If the citizen card is used in an online procedure, the citizen-card environment communicates with the procedural application. This communication is not, however, direct but rather takes place via the security layer interface. This means that applications and the security infrastructure can be developed independently of each other. Security Layer In addition to independence of the browser and operating system as communication Central Register of Residents (Zentrales Melderegister): All natural persons registered as resident in Austria are resistered in the Central Register of Residents. All persons registered are allocated a unique number the ZMR number. Confusion as to a person s identity can therefore be excluded. 28 This is an automatic process by which a personal code already used in another Member State is linked to an identity link generated on the basis of that code. 39

40 medium, the security layer also has the advantage that European signature cards can be used in the Austrian e-government system. As a specification, the security layer is freely available. 29. A prototype, 30 also freely available, has been developed for demonstration and test purposes. For the purpose of the dialogue with security layer, the applications need not recognise the specific citizen card environment but simply the definition of the display format that can be processed by that environment. The standard display format of the security layer 31 was specified on the basis of international standards (XHTML und Cascading Stylesheets 2). Moreover, restrictions are defined so that the display format is suitable to display the secure signature in a secure form. It does not permit link information or dynamic elements such as scripts. Identity link When submitting an application to an authority in electronic form, the applicant must be uniquely identified and authenticated. This entails ascertaining whether the person is really the person he or she purports to be and whether he is even authorised to submit the application. However, a person s name is not, by itself, sufficient to verify identity and therefore the identity link 32 is used for the purposes of identification and authentication. sspin Form One-way Function Identity link sourcepin Public key (1) Public key (2) Name Certificate(s) Aussteller Issuer Name Name Öff. Schlüssel (2) Public key (2) Citizen signature e.g. key (1) Authority signature sourcepin Register Authority CSP Signature pdf

41 The identity link links a person s signature certificate to a unique identifying feature the sourcepin. This link between the certificate and the person is signed electronically by the public authority. This creates a cryptographically secured link between the electronic signature of a person (the signer) and a unique identifying feature of that person. The identity link makes it possible to identify a person uniquely and in a form which can be automated in electronic communications with the authority via the sector-specific personal identifier (sspin). Citizen-card environment Citizen Secure display Citizen-card Hash computation Applications User interface Web services token PIN entry Security-Layer Memory Citizen-card environment Source: Requirements of the citizen-card environment, G. Karlinger, 2002 The citizen-card environment 33 comprises a diverse range of functions that are performed by the card: Citizen-card token. The citizen card token (e.g. chip) is the central element of the citizen-card environment. It permits the computation of cryptographic functions and serves as data memory. The token must be suitable for use as secure unit for the creation of signatures or administrative signatures. Secure electronic signature. The cryptographic signature procedure is governed by the Signature Regulation. The provider of certification services is responsible for the proper functioning of the recommended components (PIN entry, hash computation and secure display). Electronic signature and authentication. In addition to the secure electronic signature or administrative signature, there must be another key pair which allows a simple electronic signature to be created. Other key pairs. It is also possible to administer other key pairs. Data memory. Data memory can consist of several memories. There is memory in the 33 Introduction.html#glossar.Buergerkarten-Umgebung 41

42 citizen-card token. This must manage certain data such as the identity link. In many cases, other data can be stored elsewhere. A memory area on the hard disk of the computer on which the citizen card environment is operated is a possibility as is memory accessed by the environment via a web service. Infoboxes. The memory in the citizen card token is divided into logical units. For the purpose of accessing the infoboxes, the holder of the citizen card can attribute reading and writing rights. It is thus impossible for someone to access the infoboxes without the knowledge of the citizen-card holder. Development of the citizen card concept began in November Following the issue of the membership card of the Österreichische Computergesellschaft as the first citizen card in 2003, the concept can be regarded as having been implemented. Widespread use of citizen cards can be expected once the bancomat cards are issued as citizen card in Since April 2004, citizen cards in the form of mobile phone signatures are offered as an alternative to signature cards. Electronic Delivery The introduction of the electronic delivery achieves the aim of complete online transactions. The public administration s delivery service was put into operation in May Administrative procedures can now be conducted by citizens from the application stage to delivery on the Internet. as a new service electronic delivery by statute has to be implemented in line with accessibility requirements. The concept of electronic delivery is based on fundamental considerations and objectives which were taken into account during implementation: Express consent of the citizen to electronic delivery, given at the moment of registration to a delivery service of his or her choice. The registration can be revoked at any time. Electronic delivery which is independent of the form of the submission of the application and is controlled only by the wishes of the addressee. Consent to delivery is generally valid. Changes of delivery addresses can be made at any time, even during the procedure. A change or notification that electronic delivery is not possible must be notified only one public authority and not several different offices. Electronic delivery is possible even in cases in which letters are sent by the public authorities without a prior application having been submitted. Confidentiality of the electronic delivery must be guaranteed. A combination of electronic service and paper service integrating decentralised

43 printing possibilities. Trust and the ability to validate are important elements of the electronic delivery. Therefore,, for electronic delivery it has been chosen the approach of an electronic delivery service, regulated by the E-Government Act and the Electronic Delivery Act (Zustellungsgesetz). The delivery service can be compared to the place of delivery provided for in the Electronic Delivery Act. The public authorities do not necessarily deliver official documents directly on the citizen but through a delivery agent offering this service. This approach includes the possibility of engaging private providers of service functions. However, during a transitional phase, an administrative delivery service will be created to assess the initial experiences and estimate the potential volume. As soon as the market situation has been assessed, the service may also be performed by the private-sector, provided it fulfils the necessary security and organisational criteria. Delivery model The model for the electronic delivery 35 is intended, first, to be convenient for customers and, secondly, to simplify administrative procedures and create synergies and potential for savings for the authorities. These aims are to be achieved on the basis of a modular and economical delivery service. The delivery model outlines the basic components and procedural model of electronic service. The basic intention is to avoid burdening special applications with the technicalities of delivery. This is achieved by integrating the basic module MOA-ZS (basic module for integration of the electronic deliver). The necessary data protection is ensured by high-quality identification and authentication of the recipient by way of the citizen card and electronic signature. The essential components of the delivery procedure are: A delivery centre which activates an individual s electronic address and transmits the document to be delivered to the delivery agent of the person concerned. A delivery agent which accepts the document to be delivered from the administrative application and protocols it in a manner binding on the recipient and the sender. A communication system which informs the recipient of the storage of a document by , SMS or other medium. Collection of the document from the delivery agent by the recipient with the possibility to verify the official signature 36. Proof that the document has been delivered or of failure of delivery for any subsequent enquiry The authority signs the document electronically (see 19 of the E-Government Act) 43

44 The delivery procedure entails a number of steps: 1. In order to benefit from electronic delivery, the user must be identified in an adequate manner. Such identification is effected on the basis of the citizen card function. Complete identification takes place upon registration as a user of electronic service with the delivery agent. Users may register with more than one delivery agent. 2. The document is transferred to the appropriate delivery agent in encrypted form by the sending application. 3. The recipient of the document is already known to the delivery agent because he or she has previously registered with it. The data required for identification, in particular the key for encryption of the documents, are communicated upon registration. 4. The document to be delivered is collected by the recipient. If required by the public authority sending the document, the delivery agent issues an electronically signed confirmation of delivery (RSA delivery) or sends a failure to collect message to the authority. The document can be decrypted after the receipt. Documents which are not collected electronically will be delivered on paper after expiry of a fixed period. 2 notification status/proof of delivery 4 office 1 document 3 request (signed) Delivery service Transmission Source: P.Reichstädter, Electronic service of documents Model and Processes, If delivery or storage is unsuccessful, the delivery agent is to issue an "impossibility of delivery message" to the sender of the document. The user data relating to delivery must be destroyed by the delivery agent. 44

45 Generally, delivery is based on three interfaces: 1. Recipient Delivery agent. User prompting and communication takes place via websites, whilst the signature is transferred via the security layer interface. 2. Public Authority Deliveryagent. This is a two-level interface for the selection of the delivery agent and sending of the document. It is a centrally defined interface (XML and Web service) via which a standardised format is transmitted in secure form to the delivery agent. This allows the administrative body and the delivery agent to be independent of particular forms of technology and open to market-orientated competition. 3. Notification. Notification can be sent using various electronic media (SMS, fax, e- mail, etc.). The basic document format used is XML, which has a hierarchical structure. The outer layer is provided by a generic XML container structure which contains, for example, the data of the issuer and the recipient. There are more specific structures for each type of document (e.g. administrative notice). The advantage of the layered structure is the homogenisation of data which can create synergies. Owing to the XML container, any data format can be served in encrypted form. Process description The electronic delivery comprises various processes which are described in detail in the delivery concept. 37 The delivery process can be divided into a number of stages: 1. Persons wishing to have documents delivered electronically register with a delivery agent, identifying themselves with their citizen card. Identification allows the data relevant for service to be attributed uniquely to the recipient. The identification principle is described in MOA ID Before the public authority (sender application) transmits the document to the delivery agent, it must know with which agent the recipient is registered. For this purpose, it sends a request to the Delivery directory, from which it obtains information on the delivery agent used by the recipient, encryption certificates, any preferred or additional readable document formats (.html,.doc and.pdf are standard formats or, for example, plans or sketches in AutoCad format, Visio, etc.) and any notification of absence (e.g. holiday). 3. The recipient receives notification of the availability of a document from the delivery agent. Notification is sent electronically (twice at brief intervals) and, in the case of service with confirmation of service, also in paper form, where the document is not collected within the electronic notification period. 4. In order to collect the document delivered, the person entitled to collect it must identify him or herself. The documents delivered are then listed. It is possible to download the documents or forward them to an address. At the request of the sender, the delivery agent sends confirmation that the documents served has been collected by the recipient

46 5. If a document is not collected within a certain period, or in the case of refusal to accept service (not possible in the case of RSA service), an electronic notification of impossibility of service recording the failure to collect is sent to the sender. 6. If a user is temporarily unable to collect electronically delivered documents, he or she can activate a notice of absence for the delivery agent. The notice of absence is recorded in the delivery agent s directory. Documents cannot be served electronically within the meaning of the Service of Documents Act for as long as the notice is active. Documents which do not become subject to a limitation period for the lodging of any objection or appeal upon being stored for collection (e.g. an ordinary letter) can be sent at any time, even during a period of absence. 7. There must be a straightforward means of cancelling registration with the delivery agent for cases in which a recipient no longer wishes to benefit from electronic delivery. 8. The recipient must also be able subsequently to change the data provided when he or she registered. However, a modification of that information cannot be made without qualified identification. 9. The recipient s actions must be recorded in an appropriate manner. The length for which such records can be stored and the scope of the information which can be recorded are governed by the statutory framework conditions applicable to the delivery. 10. The delivery agent may offer additional services (e.g. a document safe), provided these do not prejudice the security of the system. Communication structures When documents are delivered electronically, communication is exchanged between the sender and the recipient s delivery agent via the XML interface. The interface comprises a variety of different specifications. The structure and the necessary specification profiles for the individual XML messages are set out in a document. 39 In addition to the description of the general communication structure, it contains examples of the delivery of XML and PDF messages and the transmission of confirmation of service or of a notice of impossibility of service. Delivery directory schema Where electronic delivery functions are performed by several service providers, the authority must be able to determine with which provider or providers the recipient is registered. It does so by sending a request to the central delivery service. This is a central service which communicates with all the directory services of authorised delivery agents. No information on recipients is stored in the central service itself. The specification 40 for the directories is based on the Standard Lightweight Directory Access Protocol (LDAP). The directory services of a delivery agent must meet the standards imposed by that protocol. The data are to be stored in the defined schema Interface specification

47 When served electronically, documents are transmitted by the authorities to a delivery agent. The agent then ensures that the documents are delivered to the right recipient. Technical communication between the administrative application and the delivery agent takes place via the delivery interface. This interface is defined in precise detail in order to guarantee a standardised exchange of data. The specification of the interface 41 describes the data formats of the individual elements of delivery (encrypted communication, document delivery, notices of successful or failed delivery, messages, proof of delivery, confirmation, etc.). XML specification The data structure required for the delivery 42 is, as a central component of secure e- government laid down in various other specifications. The main information consists of data on the person, the notice or decision and organisational data. Usually, an attempt was made to define as many options as possible in order to permit flexible combinations. Additional attributes are possible. Since not every element need necessarily to be used, the structure is to be understood more as an information model than a data model. Prototype Since June 2003, a prototype has been available, which was presented at the E-Government Conference in Graz in connection with the Model Online Procedure for Registration Confirmation. This prototype can be used above all for prototype implementation or the test integration of electronic service into administrative procedures. Administrative delivery agent Since May 2004, the electronic delivery service, including the delivery centre, is available as administrative delivery agent at Electronic Confirmation of Payment Applications to the public administration are not always free of charge.. This is equally true of electronic procedures. But how can fees and charges be paid electronically? To that end, the Federal e-government strategy offers the integration of payment into administrative procedures. The basis for this is provided by open and largely automated procedures which make the integration of existing payment systems possible not excluding at the same time new solutions for the future. The range of services offered covers online banking to credit cards or payment using mobile phones. Provision is even made for the integration of cash payment at the office cash desk into an electronic procedure. The principle of flexibility therefore requires applications which are not dependent on specific forms of payment. Transparency is the most important factor. It must be clear in what form payment is made. This is achieved using the EPS-2 standard. 43 EPS-2 interface The EPS-2 payment standard is an open interface between the application and the payment

48 mechanism or intermediate clearing point. The interface serves the settlement of online payments and supports various transactions. At no time are the payer s data transferred. The EPS-2 standard was developed by an inter-bank study group, the Studiengesellschaft für Zusammenarbeit im Zahlungsverkehr (STUZZA), 44 together with the federal and regional administration. It is based on the European banking standard ECBS. 45 EPS-2 has seen the creation of a global standard for online payment processes which not only allows direct payment using the various Internet banking systems of the banks but also credit card payments, payment systems based on mobile phones or cash payment (e.g. office cash desk). Payment by mobile phone and by credit card is already possible and was demonstrated by the example of the electronic confirmation of registration. 46 With the introduction of the electronic register of convictions certificate, 47 credit card payment is to be integrated into an electronic procedure for the first time. The EPS-2 Protocol lays great importance on simplicity, security and compatibility with international standards. It also provides for a guaranteed payment, for which the payment partner (e.g. the bank) assumes full liability. The advice notice or confirmation of payment is signed electronically and can thus be processed or archived as a receipt which can be subsequently verified. The modular structure of EPS-2 has various advantages: New modules can be integrated more easily. It can quickly be integrated by handlers (e.g. public authorities). International requirements can be taken into account. The basic data in the payment information are defined in a secure XML form. The specifications contain the basis for further analyses and implementation in collaboration with the Austrian public authorities. Process Where payment is made during an online procedure, the following steps will generally followed: 1. The applicant initiates the payment process. 2. A demand to pay is sent to the bank. 3. The applicant is directed to the selected bank and carries out the transaction there. 4. A check is carried out to ascertain whether it is still possible to connect to the authority. 5. The existence of a connection is confirmed by the authority

49 6. Confirmation of payment is transmitted to the authority. 7. The authority sends confirmation of receipt of payment. 8. The payment process is completed and the applicant is directed to the public authority s application. Purchaser Handler (e-shop, E-Government Bank System 11 Order or application - 2a XML message with payment - 2b Response is XML message with unique tokens (session acc. to documentation) 3a Redirect to bank-site 3b Bank replies with log-in site presenting payment information (key is session ID) 4 Customer identification, transfer 5 Vitality check to handler 5a Vitality check confirmation Bank makes transfer 6a XML message with positive or negative payment confirmation for customer 6b Confirmation of receipt of payment confirmation 7 ((Reply to 4) Redirect to e-shop/ E-Government, URL from 2a also provided. Internet Internet 49

50 50

51 Policies 51

52 The e-government sub strategies outline general standards and minimum requirements. For each specific area, defined approaches (policies) are laid down, which form a common basis for implementation. Internet Policy The Internet Policy represents an attempt to lay down common criteria for online communication between external partners (authorities, citizens and the private sector) and between the various authorities. The aim is to facilitate use by standardising the communication interfaces while at the same time satisfying the necessary security standards. The general Internet policy thus serves as the foundation for further implementation in the administration. Common communication criteria and minimum requirements make it easier for external communication partners to navigate in and use the system and heighten security: The target group of external communication partners is defined (authorities, citizens, private sector). Minimum requirements for file formats, sizes and types (restrictions, compressibility and expandability, formats which require support, etc.) are defined for each form of communication. Impermissible file formats which can be classified as potentially harmful programmes are not permitted for security reasons. They are generally rejected or their acceptance is prevented by appropriate technical measures. It should be possible to read or process documents sent by the authorities irrespective of the commercial software products of users. Specific official formats are defined. Standardised signature procedures are to be followed with respect to documents signed by the authorities. When the authorities communicate with each other, the same document formats should be used as are used in communications between authorities and citizens. Additional formats may be permitted on the basis of bilateral agreements. The security requirements to be met by the transfer of data depend on the degree of sensitivity of the data (HTTP, HTTPS, FTP, etc.). Proposals are to be made for counter measures to be taken to deal with the various risks (e.g. viruses, infiltration by hackers). Policy Citizens are increasingly using to communicate with public authorities and even the public administration is making increased use of electronic means to exchange information rapidly and efficiently. Security and reliability therefore play an important role. The 52

53 policy 48 defines general principles, requirements and recommendations with respect to communication with the public administration by . As a result, citizens can expect and rely on uniform communication structures for their dialogue with the administration. Generally, the objective to be attained is a formalised form of communication which can be automated in order to achieve maximum rationalisation. Defined procedures are intended to lead to a smooth exchange of information. With the opening of the networks, the security factor is becoming more and more important. Identity, authenticity and frequently confidentiality of information are among the essential quality criteria to be met by communication. The policy can be regarded as a package of organisational measures, basic technical requirements and defined procedures intended to serve all users as a guarantee of the secure transfer of information: The policy is, in principle, directed at the two target groups of authorities and citizens. It is on the basis of this general policy that the authorities draw up their own e- mail policy. In addition to minimum requirements and compulsory rules, the policy lists further elements to be defined by the authority. These elements are accompanied by a series of proposals in the form of best practices. The requirements are laid down on the basis of flexible, internationally available and recognised standards. Thus, the POP 3, IMAP und SMTP proposals, which are widely available worldwide, are among the transfer protocols used for client-server communication and for communications between servers. Encrypted and signed information must likewise be based on current standards (e.g. MIME und S/MIME). Moreover, requirements must be met for remote access to systems which are, in principle, similar to those applicable to other remote access rights within the authority. Further policy guidelines relating to security and the maintenance of functionality include limitations on the size of s, the exclusion of or acceptance guarantee for various file formats, checks for harmful files, spam filters and measures to be taken where these requirements have not been complied with. Guidelines for the use of electronic signatures and encryption: specific s sent by the authorities must be electronically signed by the administrative staff in as many cases as possible. This measure contributes to ensuring authenticity and increasing confidence in electronic means of communication. Guidelines Guidelines lay down general requirements to be met by e-government. Compliance with these requirements ensures that the prescribed standards, procedures and mechanisms can be applied uniformly

54 Certificates s sent by the administration must be signed in as many cases as possible. Electronic signatures are intended to increase the trustworthiness of s from the public authorities. In view of the ever greater severity of attacks by viruses, the security of communication should thereby be improved. The guidelines on certificates 49 summarise the content of certificates and the processes effected in the life cycle of a certificate (registration and revocation). Independent encryption certificates for the confidentiality of s are also recommended. Account is to be taken of the guidelines when implementing new certificates. The guidelines are revised as soon as new methods become available (e.g. directories). The guidelines are focused not only on confidential communication. In view of the difficulty involved in saving keys and back-up keys, a solution is proposed for the creation of encryption and EFS certificates. 50 An encryption application is available from A-SIT. 51 In addition, configuration settings for the user end are described and documented. An certificate is a certificate with a restricted purpose. It is used exclusively to sign electronic mail in order to guarantee the integrity of the data and to authenticate its origin. The certificate must meet certain requirements (profile standard RFC3280, designation of the official, address, administrative capacity, use of code, information on revocation, reference to certificate policy, expiry of period for request, certificate application, certificate issue, key generation, directory requests, rights to revoke and mechanisms for revocation). Server Certificates in Administration The public administration is expected to deal with data in a responsible manner. Servers of the public administration must therefore offer a high level of security for the exchange of data. It is essential that any person can recognise that such a certificate is involved and that such certificates are issued in secure form only to actual public authorities. The guidelines on server certificates 52 contain provisions on the certificate content and on the processes effected during the life cycle of a server certificate. They apply only to administrative servers bearing the domain extension gv.at. Servers can be configured and operated in various ways. In principle, each defined server on which secure authentication is carried out must have its own certificate. In order to operate a server with a secure connection (SSL), 53 a server certificate is necessary. This applies to both unilateral and reciprocal authentication. Unlike a personal certificate, a server certificate is issued for an object, namely the server, which can be accessed using a unique domain name (DNS name). That name must be contained in the certificate. The same applies to certificates required for other protocols (e.g. VPN connections via IPsec). A server certificate makes it possible to identify a server digitally because it contains Encrypted File System 51 Zentrum für Sichere Informationstechnologie Austria (Austrian Centre for Secure Information Technology), Secure Socket Layer 54

55 information on the server itself (DNS name) and the organisation responsible for the web content. Server certificates can be issued by any organisation with an appropriate infrastructure. In any event, it must be ensured that the associated root certificate is publicly available to clients for the purpose of verification and that it can be installed in an authentic manner at the client. Like administrative certificates, server certificates also contain a further enhancement of the administrative attribute by way of the object identifier. The guideline thus lays down standards and criteria for certificate content, key management, the life cycle and the infrastructural measures to be taken. Form Style Guide Until now, public administration forms could only be downloaded from the Internet. Downloading was laborious and the forms then had to be completed by hand. The new e-government system consigns this method to the past. The person concerned may complete the forms directly on the computer. They are the first link in the chain of online procedures and are signed electronically and sent to the authority over the Internet. This is made possible by the XML standard chosen, which is used worldwide for data transfers. The aim is to make standardised application forms available throughout the country. The Form Style Guide 54 contributes to a standardised layout for Internet forms. Insofar as no particular form is prescribed by statute, the authorities should design their Internet forms in keeping with the requirements of the new Style Guide. The consistent use of standardised forms offers the entire public administration an opportunity to present a uniform image to the outside world. At the same time, synergies can be produced when drawing up the forms. The similar structure facilitates navigation for users. The present diversity of layout will be replaced by a standardised form and old forms will gradually be adapted to the new standards. The public administration has declared its intention to provide undiscriminised access to its electronic services. Web forms are often the key to such services. The Form Style Guide lays down minimum requirements to be met by the public authorities with respect to the graphic design of their web forms. One of the minimum standards imposed is conformity with Level A of the internationally established WAI Guidelines. 55 The Style Guide is continuously updated by a working group 56 composed of representatives of the Federal Government, the provinces, municipalities and local authorities. Together with a description of the standard data to be contained in e-government forms, the Style Guide serves as a basis for a uniform layout of electronic forms of the public administration in Austria. The Style Guide is based on the following framework conditions: Web forms may differ from printed forms, provided that they are governed by binding statutory rules. Uniform and modular structure by the use of form components. Straightforward layout ensured by certain measures

56 Automatic completion where the data is already available. Form components designed in a way which takes account of the printed appearance. Comprehensible form, easy legibility and, where necessary, taking into account of foreign languages. Implementation of Level A of the WAI guidelines and the W3C 57 HTML/XHTML standard. Uniform font for e-government. Possibility of a partly automated generation of HTML forms. The basic design covers recurring form components such as addressee (public authority), designation (title), introductory explanation, entry suggestions, error checks, notes on the application, final text, navigation, form recognition and position in the form. The content of a form is divided into the following sections: applicant, address, application and annexes. Each component is composed of individual parts (component name, design, main text, suggestions, fields to be completed and optional fields). The Style Guide is supplemented by provisions on the use of typefaces, lines, colours, standard data, graphic elements, links and a glossary. Standard data The introduction of web-based solutions gives rise to entirely new possibilities with regard to forms. Forms can, where necessary, be structured dynamically, completed in a dialogue and immediately checked. The use of dynamic content is, however, subject to harmonisation. In the document Standard Data for E-Forms, 58 a clear description of constantly recurring data standard data is given. The type and length of data and data fields are likewise specified. The range for the individual data is described. Standard and comprehensible texts offering assistance with the filling in of the fields in the form are intended to facilitate completion. WAI Guidelines With the adoption by the heads of government of the decision on the Action Plan eeurope 2002, Austria has declared its support for the principle of non-discrimination in the field of Internet access. The Federal administration has therefore undertaken an obligation to implement at least at Level A of the WAI Guidelines 59 of the W3C Organisation. In the long term, all levels are to be gradually realised. Moreover, prompted by the conclusions of the Council of the European Union of 2002, 60 the ICT Board agreed to require compliance with Level A of the WAI Guidelines when issuing instructions for new web content. The E-Government Act places the public administration under an obligation, from 2008, to offer barrier free access in accordance with international standards of accessibility for disabled persons pdf 59 (German translation)

57 The purpose of the Web Accessibility Initiative (WAI) is to make web content accessible to all, regardless of any physical or technical restrictions. Therefore, when developing texts or multimedia products, account must be taken of the needs of people who have physical disabilities or are subject to technical limitations. Such restrictions may caused by old hard or software, a loud environment or an impaired view of the screen. The WAI Guidelines are set out in order of priority. Priority 1 (Level A) concerns absolutely essential precautionary measures which must be taken to ensure that content can be read by the target group. The most important principles are: The separation of content and style. Style elements should not be contained in the content. Where style sheets are used, it must also be possible to read the texts without style sheet. For elements such as pictures, video or graphics, a text alternative or a description must be provided. Care is to be taken with the use of colour in texts and an alternative representation without colour must be provided. Texts in foreign languages must be marked in order to alert reading tools to changes in language. The rows and columns in data tables must be labelled with headings in order to facilitate readability. In the case of more complex tables, associated data cells must be linked. It must be possible to display sites without scripts and applets. Otherwise, alternative information must be offered. Flickering screens are to be avoided or it must be possible to stop the flickering. If a site cannot be structured in an accessible way, an alternative site should be made available which must be updated in the same way as the original site. If frames are used, they must have headings to facilitate navigation. Priority 2 (or Double A) measures improve the accessibility of web content. Priority 3 (or Triple A) measures entail compliance with more extensive guidelines which make certain web content even more accessible. Compliance of the web content with the WAI Guidelines may be indicated by the conformity logo A, AA or AAA, which is conferred for that purpose by the W3C Organisation. Bearers of the logo voluntarily undertake an obligation to conform to the Guidelines. Accessibility belongs to the fundamental principles of the Austrian e-government strategy. 61 Conformity with the WAI Guidelines is therefore one of the criteria which must be fulfilled in order to obtain the Austrian e-government Quality Mark

58 Procedural/Service Sectors As a result of the distribution of competence, certain procedures can be conducted only if there is cooperation between several public authorities. For procedures that are conducted electronically within the administration, it is therefore necessary for procedural information to be networked automatically. This requires the classification of jointly defined procedural sectors. If the sectors were not classified, inter-administrative cooperation could either not be achieved at all or only at great cost or at the expense of quality. The procedural sectors of e-government (also known as service sectors) of the public administration 62 were proposed by a working group in which all levels of public administration participated and, in accordance with the E-Government Act, have been defined in a regulation. They are the highest level of an inter-organisational catalogue of services and serve as key concepts for the networking of electronic procedural information. The procedural or service sectors can be used for a variety of tasks: They are used for the derivation of sector-specific personal identifiers prescribed by statute. They serve as task areas which make it possible to categorise data applications in accordance with the Data Protection Act 2000 (relevant to the issue of whether a transfer is entailed in the use or linking of data). The uniform and systematic organisation of administrative services contributes to easier location and better understandability of Internet services of the public administration. It can also be used for other purposes such as, for example, cost and output accounting. The procedural or service sectors can be divided into external and internal sectors and individual administrative services are classed in one of those sectors. External procedural sectors include services for citizens and the private sector. PKI in Administration The Public Key Infrastructure (PKI) method ensures the authentication, identification, confidentiality and non-contestability of electronic data. Nowadays, PKI is supported by most standards and protocols and is used for the creation of a confidential and secure connection for online transactions. The most important areas in which PKI is applied are the signing of documents, secure communication and e-commerce. The setting up and operation of PKI structures within the administration is explained in the General Guidelines for the Use of PKI in Administration. 63 The guidelines are intended to assist those who are planning and implementing PKI structures in the administration. They contain information on certificate types, issuing procedures, validity, requirements to be met by the certification authority, directory services, PKI specifications, profiles, enhancements and the use of names in a PKI and in root certificates. Certificates issued by administrative bodies are indicated by an administrative attribute. A distinction is drawn between the several different kinds of certificate according to their purpose:

59 Certificates for web services for the partly automatic signature of data Server certificates used to digitally authenticate a server certificates to increase the trustworthiness of s sent by the administration Authentication certificates for authentication purposes Encryption certificates for the encryption of data Qualified certificates for cases requiring a secure electronic signature Certificates for special applications (digital tachograph, electronic passport, etc.) Without the communication partner s public key, it is impossible to verify authenticity or exchange confidential communication with the help of PKI. The storage and publication of the certificates in one or more directories facilitates the practical application of PKI. The quality of a PKI depends on the quality of the certificate issue. The creation of a highquality PKI means that, for example for the issue of qualified certificates, strict conditions must be met by the certification authority. Users must use certificates and the related keys responsibly. Issues such as benefits, purpose, use, protection of private keys, conditions of storage and revocation must therefore be set out in the cautionary text. Roles and rights must be kept separate from the certificate. The gv.at Domain Directories are used to store certificates and certificate revocation lists (CRLs). Directories are essential for the useful application of PKI in public administration. The details of the key elements of directories are set out in the Guidelines on PKI Directories of the gv.at domain: 64 Public keys are required for encrypted communication and to verify electronic signatures. Signature and encryption certificates are therefore published in directories. Access to the directory must be open to all and free of charge and is obtained via LDAP and HTTP protocols. The certificate status (period of validity and validity) can be determined by way of a CRL 65 request. For data-protection reasons, a distinction is drawn between public and trusted access. Access rights are granted according to the nature of the access. In the case of access from trusted networks of the public administration (e.g. from *.CNA.AT), extended access rights are granted. Technical methods can be used for that purpose, which require a greater degree of qualification. Depending on whether certificates are accessed via an LDAP or HTTP protocol, certain access requirements must be complied with Certificate Revocation List 59

60 Read access to the directory is not subject to any particular protective mechanism since data relevant to the PKI is signed by the issuer of the certificate. Such access can, however, be restricted on the basis of need, provided such restricted access serves the purpose of the security application. Write access is subject to authentication and encryption. Basic services Durable e-government requires more than just a straightforward organisational structure. In addition to uniform strategic approaches, common solutions must be developed which offer savings and a more efficient use of resources for all participants. Common tools are an enormous help to the public authorities, which are to implement electronic services in accordance with the strategies. Online procedures can be made available relatively quickly by integrating the basic components into existing applications. Incompatible multiple developments are thus avoided. The interoperability of the procedures offered is guaranteed by the use of standardised defined interfaces and basic tools. The progress made to date in the implementation of new e-government services is to a large extent attributable to the basic components which the Federal Government has made available free of charge. The joint development process began with the Online Application Modules (MOA) and the components. Application modules for the delivery, payment and other standard submissions followed. The federal administration, provinces, municipalities, local authorities and other administrative bodies use these tools to implement electronic services. Online Application Modules Online application modules (MOA) are components intended to facilitate the use of electronic signatures and other applications such as the service of documents by the administration. The MOAs were developed at the request of the Federal Chancellery and the Federal Ministry of Finance. They are freely available for use by all public-sector institutions. Therefore, no licence costs are incurred. The online application modules serve as a tool for the efficient and secure creation of e- government applications. The first MOAs to be developed made signature verification (SP), signature creation (SS) and the identification and authentication of persons (ID) possible. The MOAs are continuously adapted to new standards. On the basis of the published specifications, details unrelated to implementation were set out in particularised specifications for all three modules. In February 2003, dummy modules (schema conform interface implementations) for signature verification and signature creation were made available to facilitate integration into online applications. MOA module specification A revised version V 1.1 is already available for the signature verification and creation module, which contains some minor additions to the original version V 1.0. The initial 2002 version V 1.0 of the identification and authentication module has likewise been supplemented and 60

61 enhanced by certain new functions. 66 MOA SP and MOA SS The specification 67 defines general requirements such as platforms, authentication, scalability, availability, logging and namespace. In addition, it must be possible to run the two modules both simultaneously and separately on the same computer. They must provide certain configuration options (client applications, profiles, certification service providers, etc.). A modular structure enables a variety of different components to be used for signature verification and creation. The architecture is therefore based on two blocks (front end and back end), which must meet defined criteria. The functions of the front end include administration of the configuration data, receipt of requests, verification of the certificate status, transfer of the data request for processing, structure of the response and transmission of the response. The back end is responsible for cryptographic operations (signature verification and creation). The functionality of the MOA SP und MOA SS can be activated via both SOAP and API. 68 MOA SP The module contains all the functionalities of signature verification which can be used by online applications. It supports both signatures conforming to the security layer and XMLDSig and CMS signatures. These can be simple or secure signatures. In any event, it must be possible to verify the signatures used by the certificates of a certification service provider accredited in Austria. Verification covers both XMLDSig signatures created in accordance with the security layer specification and signatures conforming to the XMLDSig recommendations of the W3C Organisation. 69 Request and reply modus is orientated in conformity with the message format of the security layer (XMLDSig). The signature verification process is defined in the function description. The interface consists of an XML-based request and enquiry message. The XML schema is described in the MOA schema. If the signature format to be verified does not conform to the specification of the security layer, certain requirements must be fulfilled. In the case of CMS signatures, signatures which conform to the security layer specification and signatures based on the RFC 2630 standard can be verified. As in the case of verification of XMLDSig signatures, the request and enquiry format, process, interface, signature format, certificate format and CRL archiving are defined in detail. MOA SS The basic module server signature contains the entire functionality of signature creation on the server. It supports signatures conforming to the security layer and XMLDSig signatures. The function XMLDSig Server Signature in accordance with the security layer leads to the creation of a simple XMLDSig signature based on the security layer specification. When creating the server signature, account must be taken of the need to reconstruct the electronic signature from the printed form. It must be possible to create it using both software

62 and HSM. 70 The process is divided into the following steps: determination of the signature key, certificate verification and creation of the signature. Batch signatures can be carried out, which entails the creation of multiple signatures with a single key. MOA ID This module 71 enables users conducting online procedures with a citizen card to be identified and authenticated securely. Using the module, applications can securely link a sector-specific personal identifier (sspin) or other user-specific date to an http session. MOA ID supports: the choice of citizen-card environment. communication with the front end browser and the citizen-card environment. authentication of the citizen or administrative official. generation of the sspin. forwarding of registration data. configuration of the MOA ID and handling of errors. The MOA ID consists of an authentication component and the proxy component. The authentication component ensures that the person is authenticated and transmits the registration data to the proxy component. The proxy component completes registration with the online application and takes over the transfer of data between the online application and the front end. Both components can be used on different computers. New e-government applications are capable of assuming the functionality and interface of the proxy component. The specification lays down the general requirements which the MOA ID must satisfy. The configuration of the authentication and proxy components is defined precisely. The authentication component (the root certificate) is always contacted by an application. A URL stored by the component is thereby activated by the user s web browser. The citizen-card environment is then activated, which makes it possible to read the citizen card. It is essential for the security of the identification module that the user can verify the authenticity of the authentication component in a reliable manner. Once the identity link has been successfully verified, signature can take place. The application is activated by the authentication component and carries out authentication. The client/server interface can be activated via SOAP and API. The proxy component makes it possible to link existing online applications to the authentication component. For this purpose, a class is activated within the proxy component which implements a defined interface. Online applications are divided into two categories (stateless, stateful). The particular functions to be performed by the proxy component depend on the category. 70 Host Security Module, Hardware Security Module

63 MOA List The MOA List for mailing lists 72 deals with questions relating to organisational matters. Developer List The mailing list Developer List 73 concerns issues to be dealt with by application developers which arise in the course of the technical implementation. In order to facilitate the implementation of online procedures, further modules with the following functions are being developed: MOA GEBEP This module is intended to make it possible to verify electronic administrative notices. The module takes account of the official signature and serves as the basis for the reconstruction of paper notices, which for the time being can be carried out automatically. MOA HABE This module enables clients to calculate and verify hash values. It is used for the implementation of linked attachments (e.g. e-procurement). MOA VV Online administrative procedures can also be conducted by third parties (representatives), provided that they have been granted a valid authority by the person concerned. In order to technically implement this possibility, a module for online applications must be made available which can cope with electronic mandate and rules on representation. The MOA VV carries out an evaluation of the authority, assumes the task of verifying an authority (or authority chain) and connects to the MOA ID or other applications. MOA ID+ Following the entry into force of the E-Government Act, it was necessary to enhance the existing modules for online applications for identification (MOA ID) on the basis of the citizen card. The enhanced module will be based on the sourcepin rather than the number in the Central Register of Residents (ZMR number) and will be capable of applying Kerberos as a mechanism for authentication of applications. Moreover, it will establish connections to MOA PKV (encrypted sector-specific personal identifiers) and MOA VV (authorities and representatives). MOA SL The security layer 74 is available for downloading

64 MOA SLEU This module guarantees the integration of EU signature cards into the security layer. The aim is to achieve the automatic assumption of the identification carried out in an identification system of the relevant partner state. The security layer supplement automatically recognises the card. The SourcePIN Register Authority generates an identity link on the basis of the certificate and the person s unique code number. The identity link created also includes the country code of the Member State concerned (e.g. IT for Italy). The first level of the security layer model code is being implemented using Italy as an example. MOA Encryption In order to guarantee data protection and security, data is encrypted. The CMS module for the encryption and decryption of files is a user-friendly tool, with which sensitive data can be encrypted. The encryption module is also used for the electronic service of documents. MOA ZS The delivery module for online applications creates the interface for such delivery. Using the MOA ZS, 75 rules can be established to govern the means of delivery, communication with the delivery agent, the activation of the official signature and the encryption of content of the document to be delivered. The module relieves the application developers of fundamental steps of the delivery procedure and thus contributes to a quicker and more cost-effective availability of the electronic delivery. In order to facilitate its application, a model implementation project is being carried out in the context of the ERS by means of standard text-processing. application app2mzs Receiving of to be delivered items Check if deliverable electronically Official signature process mzs2szr app2zkopf mzs2mss Sector-specific personal identifiers (sspins) Checking of Delivery Directory-Service Basic module MOA-SS (Official signature) 4 Encrypting process (optional) Source: 5 Delivery of item(s) itself app2zuse Delivery Service P.Reichstädter, Functionalities of the MOA-ZS module, May 2004 MOA DSIG MOA DSIG provides a web service and web surface for the purposes of the signature of various document formats (Winword, RTF, Open Office). Using the module, the documents can be converted to XML and signed with a standard security layer. It is thus possible to sign such document formats securely. MOA DSIG is used to sign documents annexed to a form or forms that have not yet been fully integrated into the back-office process. MOA PKV This module makes it possible to encrypt sector-specific personal identifiers (sspins) in cases

65 situations in which an sspin is identified at the beginning of the procedure but may not be stored in the form of clear text. MOA PKV also provides the decryption mechanism. Inter-Administrative Directory Service The electronic procedures initiated by citizens are processed by the public authorities internally. However, this does not mean that all officials may access all procedures. In order to maintain data protection, access rights are granted to officials within the organisation. It is therefore important properly to manage the competences and access rights of officials and organisational units. In electronic systems, directories are used for this purpose. Such directories are automated systems which record objects and attributes. In addition to the management of access rights, internal telephone directories or organigrammes can be represented in directories. The aim is to manage information on the organisation of the public administration and its staff in an up-to-date and accurate way. The basic information recorded includes first name, surname, address, telephone number, address, organisational unit, function and rights. The collection of the existing information and access rights of the staff of various authorities in a central directory produces multiple savings and synergies: Electronic staff directories and organigrammes of the public administration make it easier for citizens to gain an overview of the administrative structure and to identify contact persons. Widespread availability and the inclusion of levels of administration therefore improve transparency. Web portals can cooperate with decentralised user administration, standard menu operations and single sign-on. The existing data are updated by the relevant organisation. They can be used by all authorities participating in the directory. This means that the simultaneous maintenance of different directories can be avoided. The central directory can be automatically updated on a daily basis. The administration of access rights is decentralised, that is to say, they are administered by the authority to which the users belong. A directory presents the existing source data and resources of an organisation in a standard form. Applications can access this information via defined interfaces. Information on users is made available in a less costly and more time-saving manner. If the authority uses internal electronic record systems, data on organisational units, addresses and other information required can be taken from the directory automatically when processing those files. The directory is based on the open source approach. Supplementary entries and amendments can be made in consultation with the ICT Strategy Unit; these must, however, again be freely accessible to all administrative units. The data can only be read by users. The exchange of data takes place via the standard 65

66 communication protocol LDAP. 76 The data is maintained by way of an upload or an application. Applications which can automatically provide basic information, such as personnel administration systems, are suitable for use as data sources for the directory. LDAP Schema The LDAP Schema specification 77 defines all data which are presented in the directory, together with their properties and the interrelation between them. The specification is divided into two parts in which objects are defined to represent persons, structural organisation, contacts, address book and rights systems: The ldap.gv.at directory contains details of independent administrative units at various levels (Federal Government, provinces, municipalities, local authorities, self-governing bodies, etc.). Object classes are defined for structural organisation, personal entries and user administration. A directory information tree is defined in which the various related branches are depicted (organisation, person, function, rights, etc.). The specification contains a description of the cooperation of web portals with delegated user administration, a standard menu operation and single sign on. The information on the portal (user, applications, rights) is described. Directory service Portal authority A authoritya.gv.at User Administration authority A Portal authority B authorityb.gv.at User Administration authority B Portal authority C authorityc.gv.at User Administration authority C Definition and process of decentralised user administration. Pilot project In 2002, a prototype implementation of a directory was completed. Tests with clients offered an insight into the compatibility with the current market products. The project results 78 are available to all administrative units. Medium and long-term broad data connections in ldap.gv.at and application links (e.g. ERS) will follow on the basis of the pilot phase. The ICT Strategy Unit will present a concept for continuation of the system. The operational models to be developed will be designed in a flexible manner in order to allow for decentralised subsystems. The initial directory will act as the central node. A small number of sub-nodes will operate a directory for their own sector. The operational costs are to be borne by the relevant authority. 76 Ligthweight Directory Access Protocol

67 Application ADRESSBUCH V 1.0 The pilot application Address Book is a publicly accessible web application 79 which provides contact information for public officials (name, organisation, address, telephone numbers and address). The information will be accessible by several means. In addition to a simple search, an advanced search and a representation in the form of a dynamic organigramme are available. Standard Submission In most cases, forms are used to make submissions to the authorities. Where no particular form is prescribed by statute, citizens can submit requests in any form. In conventional procedures, electronic communication took place by , with the result that neither could the identity and authenticity of the applicant be verified nor, in the case of an incorrect address, was further communication possible. In the event of technical failure during communication, it was possible that annexes would be lost. It is hoped that the standard submission will eliminate all these defects. Requests, concerns and other submissions which need not take a particular form and do not require a visit in person can be securely transmitted to the authority, together with any attachments. Basically, a web form is used, to which annexes may be attached. The form can be completed directly onscreen, signed electronically and automatically sent to the authority. Once the form is received, the authority establishes, by way of signature verification, whether the person concerned is the person who actually sent the form. The signed form also guarantees that annexes arrive securely and without any possibility of forgery and can be uniquely attributed to a particular person. The standard submission has been implemented in a standardised form. As a result, the internal processing of the forms by the administration can be carried out automatically as part of the working method introduced with the electronic record system. The direct integration of the standard submission into the ERS system means that the citizen s concern can be dealt with more quickly. Compliance with the WAI guidelines is ensured by forms which conform to the Form Style Guide. What all must be taken into consideration? Users require a citizen card which is contacted via an HTML browser. Personal data are entered into the form automatically as the citizen card is used for an identified transfer. Annexes are securely attached to the standard submission by encryption (hash value). It can therefore be proven at any time that those annexes were attached to the original submission. Extra text may be entered. In cases, in which a scanned form is attached to the submission (e.g. a downloaded PDF form which has been filled in), additional text may not be necessary

68 Once the form has been completed, it is presented to the user for final checking. It is signed by clicking on the signature button. The resulting signed form is sent to the user and can be saved for the purposes of subsequent proof. Each form is given a unique number so that it can subsequently be traced. The sectorspecific personal identifier is used by the authorities to identify the applicant. Signed correspondence is archived and forwarded in a qualified manner. Correspondence bearing the wrong or no address is rejected. The correspondence will normally arrive at the secretariat of the authority, a previously defined electronic mailbox or an electronic collection point. The standard submission forms of the various public authorities can be distinguished by the logo, a link in the letterhead and the colour. Standardised submission forms are more convenient for users and make it possible to reduce throughput time. To promote their use, the standard submission form will be made freely available to all public authorities in two versions: Version A can be converted into server script without any active components in the browser, in order to comply with the various levels of the WAI Guidelines. 2. Version B uses JavaScript and servlets. This means that the client must have JavaScript and therefore requires less user interaction. Model Application Sustainable e-government solutions must be structured in modular form. This means that one can react quickly and cost-effectively to changing technical and legal framework conditions. A modular structure makes it possible to adapt individual elements selectively. Most e-government procedures are conducted in the same way: an electronic application is created directly onscreen by the person concerned, electronically signed and sent to the public authority. Where costs are incurred, these are paid electronically. If the application is approved, the signed document of the authority can be sent electronically to the recipient. A complete transaction therefore comprises recurring basic elements (electronic form, electronic signature, electronic payment, document signed by the authority, electronic delivery). In order to facilitate the implementation of e-government procedures, particularly during the initial phase, a model procedure was developed. This model was intended to demonstrate how the individual e-government components can be implemented in their entirety. The online confirmation of residence 81 was used as an example of model e-government. The most important components of any electronic procedure are: 1. Completion of an application form on the Web. 2. If required by the procedure, electronic identification of the person and signature of the application

69 3. Electronic payment of any costs incurred. 4. Electronic delivery of an official certificate, which can also be used in paper form for other purposes. The entire process of electronic confirmation of residence lasts no longer than two minutes: diversification * ID* Process independent electronic delivery sign to proof access Identification identity link :: diversification automatic form fill (minimum input) ID** diversification ** payment Electronic signature to allow use of private data to authenticate Source: R.Posch, eday Presentation, Confirmation of residence certificate can be requested via the administrative portal help.gv.at. 83 Citizens call up the online form. Before completing the web form, the kind of citizen card (chip card or mobile telephone) must be selected. If a mobile phone is used as a citizen card for the first time, the user must register on the e-government portal of the telephone company with a user ID and password. Having authorised the reading of his or her identity link, the applicant is then authenticated. The fully completed form, together with information on any costs, is displayed. A mobile-phone signature is triggered by entry of the signature PIN and the transaction code which has been communicated by SMS. Selection of the method of payment. If payment is made by phone (Paybox), the owner of the mobile phone receives a telephone call from Paybox. The amount to be

70 paid is stated and the owner is asked to enter a payment PIN. Confirmation of payment is sent by SMS. The user receives an onscreen message that the certificate requested can be collected from the delivery server. The recipient of the certificate identifies him or herself on the delivery server with his or her citizen card and collects the certificate. Since the confirmation of residence procedure was implemented in June 2003, a series of other online procedures using electronic signatures have been made available at federal and local level. All these procedures can be accessed via help.gv: Child-care allowance Electronic social insurance Standard submission Registration and notification of change of address Copy of birth certificate Copy of marriage certificate Notification of interior construction work Notification of start of construction work Notification of change of waste containers Registration of wine bars Nursery registration Certificate from the Register of Convictions E-grants E-tendering Centre for reporting child pornography Centre for reporting environmental crime Centre for reporting repeat offences Trading registration Community tax return Notification of events Water-meter reading Since June 2004, Finanz Online has, in addition to online registration, offered a service for registration with the citizen card. Registration becomes even easier. Instead of three access codes (participant identification, user identification and PIN number), users identify themselves with their citizen card. If a signature card is used, only the PIN code need be entered. In the case of identification by mobile phone, the unique transaction number, which is received by SMS and the PIN are entered. The registration with a citizen card make the immediate use of the Finanz Online services possible. There is no longer any need to wait for the access codes to arrive by post. 70

71 Administrative Portal help.gv Information and services provided by the public administration must satisfy certain quality standards and be reliable, trustworthy and accessible to all. Citizens are guided to the electronic services of public administration by Internet portals. In order to facilitate access to the Internet services offered, the already existing administrative portal help.gv is being extended to become a transaction portal. All services provided by the public administration are to be accessible via this central point. In order to gain such access, citizens need not be familiar with administrative areas of competence but can direct their search for information according to life events (businesses according to business circumstances). In this way a further principle laid down by the European Union in the field of e-government, the one-stop principle is implemented. Help.gv is the central mechanism making it possible to offer procedures relating to all areas of administration to the public. Standardised forms and application processes make it easier for users to use the services offered. Within the administration, help.gv supports the transfer of the electronic forms to the electronic record system and to automated procedures such as, for example, Finanz Online. 71

72 72

73 Inter-Administrative Cooperation 73

74 The progress achieved to date in the development of e-government is to a large extent the result of the intensive cooperation between federal, regional and local public authorities. The closely coordinated action and the practical involvement in joint projects have lead to an integrated approach. The previous voluntary coordination has been replaced by compulsory cooperation. Formerly partial solutions have now been replaced by a nationwide, uniform system of e-government. This feature distinguishes Austrian e-government from the approaches taken in other EU States. Online procedures offered to citizens must be based on the same standards and processes so that a comprehensive interaction of administrative bodies is possible. Citizens can then be offered a uniform system of e-government. Together with the provinces, municipalities and local authorities, the ICT Board lays down the strategy to be adopted in and the technical standards to be met by all activities at the federal level. Information is regularly exchanged between the local bodies and the Head of the ICT Board for the purpose of coordinating the action to be taken. The consistently intensive cooperation is made possible by the sharing of information on e- government tools. Basic e-government services and tools are made freely available to all administrative bodies and organisations. Rapid and uniform implementation is therefore ensured. This also represents a practical implementation of an EU measure adopted in the context of eeurope. Not only the provinces, municipalities and local authorities cooperate in the implementation of e-government. Discussions are continuously held with all actors offering e-government services or affected by the implementation of e-government concepts. Such entities include, for example: Social insurance institutions: Issue of the e-card, provision of online services, back office integration Chambers of Commerce: issue to members of signature cards suitable for use as a citizen card, implementation of online services for undertakings, register of businesses Universities: issue of student cards which can be used as citizen cards, e-voting in university elections Österreichische Computergesellschaft: Pioneer role in issuing citizen cards to its members Medical Council, Pharmacists Council, hospitals and clinics: back office integration Federal agencies, Statistik Austria and others Regarding issues of security, signatures and encryption, there is cooperation with A-SIT, as was proposed in the Council of Ministers presentation of 6 July In 2002, the institutionalised cooperation between the federal, regional and local authorities was enshrined in a convention: 84 In the convention, all partners declare their willingness to implement a uniform system

75 of e-government interfaces and basic functions. Self-governing bodies and other authorities are likewise to be involved. All actors involved may set up working groups for the individual sectors and inform the others thereof. All partners can take part in the working groups. The intermediate conclusions reached by the working group can be made known to a wider circle of interested bodies or persons. Undertakings may form part of the wider circle of interested bodies. For each area, a person is to be appointed to take on responsibility for establishing a working and communication structure together with the members of the working group. Any proposals are to be communicated to the ICT Board, the working groups of the provinces, the municipalities and local authorities for deliberation and voting. The results will be published. Even if no consensus is reached, the proposals may be implemented where agreement is reached as to improvements. Documentation is to be drawn up in accordance with certain criteria (name, short name, brief description, authors, etc.). The working group and the circle of interested persons will each maintain their own mailing lists. Portal Group Essential to uniform e-government is properly functioning cooperation between all administrative authorities which extends beyond local boundaries. One result of the good cooperation between the federal, regional and local public administrations is the portal group. By linking administrative portals, the data applications of individual authorities are made available as a package. Which application is made available via which portal is determined by the operator of the application. The operator defines which administrative units have access rights in accordance with the relevant statutory provisions on data protection. Users rights of access for users are defined in accordance with their functions. The operators of application portals can delegate authentication and authorisation of access to other portals (Base Portals). The advantages include reduced expenditure for the user administration and simpler management of access rights as a result of single sign-on. The maintenance of parallel directories is no longer necessary. The duplicate developments which arose in the past can be prevented, with the result that all involved save costs. The portal group is a link up of administrative portals for the purpose of joint use of the existing infrastructure. The operators of portals of the federal administration are called upon to implement the Portal Group Agreement (PVV). The interconnected system enables participating organisations to use their own user administration even for external applications. The application operators therefore do not need to administer the user rights of external participants. The applications themselves are web applications based on HTTP or SOAP protocols. 75

76 General information on the structure and functioning of the portal group system is provided in the Portal Group White Paper: 85 The portal group allows several applications to be accessed from one central point. Data applications in the Portal group can be accessed only by users which have been authorised to do so by their base portal. The rights profile is verified to determine whether it is consistent with the competence of the unit authorised to access the portal. Users must identify themselves upon registration. In addition, data-security measures must be organised and implemented. User administration remains the task of the unit to whose staff the user belongs. Local authority bodies, other public-law entities and other institutions performing public functions may join the portal group. Communications within the group are governed by the portal group protocol and the definitions of the security categories. The employees of institutions which participate in the Portal group are not affected by any changes. In order to join the federation, a membership declaration 86 must be completed and lodged with the depositary (Federal Ministry responsible for federal IT coordination). The publication of the membership declarations 87 contains a list of the participants who have newly joined. Participation in the portal group is governed by the Portal Group Agreement. 88 That agreement sets out the rights and duties with which the partners that have joined must comply: The agreement defines basic terms such as portal, base portal, application portal, portal group system, participant, user, portal operator, etc. It lays down the rights and duties of the application operator (availability times, conditions for rights of access, conditions of use, monitoring of the grant of rights, inspection of the control measures of the base portal). The operator of the application portal must comply with certain rights and duties (e.g. plausibility checks of the access and rights profile, monitoring of user rights, implementation of data-security measures, plan of action for malfunctions). There are also rights and duties for the operator of the base portal (organisation, user administration, creation of access profiles, entry of access rights, user caution, annual security review). The unit with access authorisation is granted certain rights and undertakes certain obligations (allocation of access rights, distribution of rights profiles). The other duties of the portal operator include the recording and storage of datasecurity measures and the publication of contact persons. Technical and organisational precautionary measures must be adopted (minimum

77 standards, requirements to be met by equipment for communication within the portal group). Service providers must comply with data-protection provisions and adopt data-security measures. There are rules on the withdrawal of access authorisation. The final provisions lay down the conditions for the exit of a participant. Annexes 1 and 2 contain the specifications of the portal group protocol and the security categories in the portal group. 89 The portal group protocol 90 defines communication between administrative portals: The user authenticates him or herself at the base protocol, which authenticates and authorises him or her via the portal group protocol (PVP) at the application portal. The PVP can be used with different protocols (HTTP; SOAP). In addition to the Portal group Agreement, the terms rights profile and allocation data are defined. The notation and grammar (list of parameters) are described. The way in which the PVP is linked to the HTTP protocol is defined. The portal architecture, error messages and the URL structure for application portals are described. Security is ensured by certificates which bear uniform attributes. The confidentiality settings of work stations are subject to a clear schema. One of the first applications to become available in the portal group was the Central Register of Residents. The Register of Company Names and a land database will soon follow. Project Model Communities Citizens and businesses have to deal with the administration not only at federal and regional level. A large number of procedures are conducted by district councils and local authorities. Whether it be planning permission, funding for associations, administration of parking spaces, refuse collection or registration of events a variety of procedures must be initiated at local authority level. In order to provide a comprehensive system of e-government, it is important that local authorities are included in the process. Today, the majority of Austrian local authorities have a website on the Internet. In addition to information on local activities and Internet procedures, electronic services are even now 89 SecClass, currently Version 1.0.0/ , 90 Portal group protocol pvp Version 1.7.0/ , 77

78 available in some form. Downloadable forms, s to the local authority or the conduct of procedures with a user ID and password for registered users are currently on offer. However, like the federal and regional public administration, local authorities now face the challenge of adapting their current services to meet new demands and standards required by e- government. Accessibility, security and uniformity are just some of the objectives to be achieved. The Project Model Communities was intended to demonstrate how the new basic components and security elements of e-government such as the web form, electronic signature, electronic payment and electronic delivery could be integrated in line with strategy into existing IT systems and applications in the back office. The project was initiated by the Federal Chancellery in cooperation with the Federation of Local Communities, with the aim of enabling all local authorities to benefit from the experience acquired in implementing e- government through a virtual network of competences. A further objective of the project was to ensure that the sphere of influence is not restricted only to the administrative environment. The importance of e-government as a motor for the development of e-commerce is becoming more and more apparent. Extending the scope of application was intended to demonstrate that even the private sector can use e-government developments such as the electronic signature. Not only procedures were to be improved but also the facilities for accessing e-government via public terminals or local wireless networks (WLAN). The Project Model Communities serves as an example for all local authorities wishing to provide their citizens with greater service by way of electronic services. Four local authorities, in both city and rural areas, were selected to serve as model communities. The participants in the project were Bregenz, Kufstein, Inzersdorf-Getzersdorf and Weikersdorf. During the implementation, synergies were produced which allowed, for example, the joint development of web forms. In practical terms, currently available web services have been adapted to e-government procedures conforming to the strategy. Rather than making forms available for downloading, web forms are used which can be competed directly and automatically sent to the authority. The web forms are based on the Style Guide and the XML standard. Unlike the situation previously, the forms are signed by the applicant electronically. This ensures that a third party cannot purport to be someone else. By verifying the signature, the authority can uniquely identify and authenticate the applicant. Any procedural costs incurred can be paid immediately upon completion of the form by a variety of payment methods (credit cards, mobile phones, online banking). The procedures offered can be accessed easily via the administrative portal Unlike an office, the portal is never closed. Citizens can complete applications round the clock. The model local authorities themselves need no longer to implement tasks which are carried out by the administrative portal. Various pilot procedures were implemented in the four local communities, including: Notification of building work Change of waste containers Parking entitlement 78

79 Water-meter readings Communication between parents and primary/nursery school Registration of wine bars The Project Model Communities came to an end at the end of March The electronic services of the local authorities which were realised in accordance with the strategy are to be awarded the e-government Quality Mark. Even now, after the end of the project, the four local authorities continue to work on the shift to e-government. Many other local authorities have already shown an interest in offering the procedures which have been developed within the framework of the project. Citizen Card Community Hitzendorf The citizen card plays a central role in the Austrian system of e-government. It is used in online administrative procedures to identify and authenticate the applicant. This guarantees that the data cannot be accessed by unauthorised third parties. The use of the citizen card to deal with electronic public administrations is new and unusual. The users must first become accustomed to its use. Even in Europe, there are still very few Member States in which citizen cards and electronic signatures are used in administrative procedures. It is therefore important to gain more general experience of the benefits, effects and potential of the citizen card. Precisely this is the objective of the Hitzendorf Citizen Card Project. Taking part in the project are the federal administration, the market town Hitzendorf, the region of Styria and a number of private firms, 91 which have provided the equipment and services free of charge. Those inhabitants of Hitzendorf wishing to participate in the project receive a citizen card for two years free of charge. Each of the participants is equipped with a signature card, a card reader and a mobile-phone signature. They are assisted in installing and setting up the card reader and software. The project began in April 2004 with a focus group of 38 people of various age groups and with technical knowledge varying in degree from none to good. The members of the focus group have already begun to test the online procedures available. A larger-scale involving all volunteers is scheduled to begin in autumn The use of the citizen card is not restricted to online services provided by Hitzendorf, the region of Styria or the federal e-government but also includes e-banking. The conventional process of entering a user number, account holder and TAN 92 is thus no longer necessary. In order to encourage the inhabitants of Hitzendorf to take up the opportunity, a bank 93 has offered them a current account free of fees for one year. A further use of the citizen card is access to e-learning services and discussions with the largest provider of e-learning services in Austria are underway. The project has already led to a number of changes for Hitzendorf. The town s website has already been adapted to the new demands. Special administrative help pages have been set up and the administrative portal help.gv has been integrated for this purpose. In addition to general information on e-government and the citizen-card concept, the local authority s 91 The business partners of Hitzendorf are A-Trust, together with its partner firms BDC and Reiner-SCT, Mobilkom Austria AG, Comm-Unity EDV GmbH and ITCM IT Concepts Mauerhofer 92 Transaction number 93 BAWAG-PSK 79

80 own e-government page offers central access to all the e-government services provided by Hitzendorf. The services currently offered are being adapted to the new e-government standards and new citizen-card procedures. At present, several procedures can already be conducted online (birth certificates, child-care allowance, communal tax return, registration confirmation and certificate from the register of convictions). The aim is to offer the citizens of Hitzendorf as many electronic services entailing use of the citizen card as possible. Funding applications specific to the local authority and identified inspection by citizens of fiscal records are planned. It is also planned to integrate the electronic delivery of documents by autumn Administrative notices and prescriptions can thus be delivered electronically on participants. It is no longer necessary to go to the post office to collect documents. In the course of the Project Citizen Card Community, information can be gleaned as to the extent to which the citizen card is accepted by citizens, the amount of use made of it, problems arising during its use and difficulties in technical implementation. On the basis of the experience gained, improvements can be made in the range of e-government services offered with a view to making them more convenient and user friendly. The project also offers a real opportunity to investigate new partnerships between the public and private sectors. All those involved in e-government can profit from the synergies produced. Working Groups The cooperation in the development of e-government also takes the form of numerous interadministrative working groups. The working groups are composed of representatives of the federal, regional and local authorities. Their task is jointly to draw up and coordinate the basic components of e-government. E-Government Group of the Regions In order to provide a uniform system of e-government, intensive cooperation beyond the existing levels of administration is required. Such cooperation is guaranteed by the working group of the federal, regions and local authorities, in which the federal administration, regions, Austrian Federation of Municipalities and the Austrian Federation of Local Communities devise joint solutions for legal, technical and organisational issues. The requisite transparency is ensured by a common information and communication platform. 94 In several other working groups, concepts, specifications and models are elaborated for specific areas:

81 Form Style Guide Inter-administrative authorisation system Network of procedural information Communication architecture Service of documents PM-SAP Directories ERS Security handbook LDAP MOA OLAPP E-government roadmap working groups Representatives of various administrative units participate in the implementation of the roadmap projects for their own particular area of focus. At present, there are active approximately 15 working groups

82 82

83 Infrastructure 83

84 Electronic Record System (ERS) The rapid spread of electronic media has resulted in an ever more intensive use of such media for communication with public authorities. The public administration must therefore have an adequate infrastructure at its disposal. At the same time, internal administrative processes must be automated and optimised in order to be able to provide satisfactory e-government services. The introduction of the electronic record system at federal level in 2004 has meant that many procedures can now be conducted more speedily. The use of the electronic record system supports the processing of more complex procedures which cannot be carried out by wholly automated means. The reaction and processing time can be reduced by approximately 10-15%. As soon as the system has been implemented in all Federal Ministries, inter-administrative transactions can be processed by way of just one medium. The global introduction of the electronic record system is underway in several provincial administrations. The ERS is based on the following fundamental principles: 1. The electronic record (digital documents and information relevant to a procedure) is the original. Printouts are regarded only as copies. 2. All administrative units and staff are involved in the ERS. 3. Changes of media (printing and scanning) are to be avoided. In contrast to conventional methods of working, the ERS makes it possible to: carry out processes simultaneously. make information available, provided that the requisite access rights exist. carry out research directly from working stations. depart from distribution and filing structures. make processes transparent. standardise working methods. enable all participating administrative units to inspect the record. Electronic record systems contribute to avoiding changes of media. This is achieved by way of a series of defined interfaces which permit communication with the staff and applications involved. 84

85 Entry interface Applications which are submitted electronically by way of a web form can, as a result of their standard XML format, be directly integrated into the electronic record system and processed. There is no need to print or scan it. The incoming application is immediately transmitted to the competent administrative unit for processing. EPS 2 interface If an electronic submission gives rise to costs, these can be paid immediately by way of online banking, by credit card or by mobile phone. The electronic confirmation of payment is transmitted directly to the public authority. Interface for the electronic delivery agent Documents drawn up by the public administration are not sent directly to the recipient but to an electronic delivery agent which delivers the document on behalf of the authority. Process-modulation interface In adapting the traditional system of processing records to electronic procedures, an optimum working method must be selected. For this purpose, process-modulation tools are used which can be activated via the standardised interface. Interfaces with other applications A procedure may require information which can be obtained by automated means from other administrative applications (e.g. register, SAP, LDAP). 96 Communication takes place via defined interfaces which permit a standardised exchange of data. E-Law The initiative for the setting up of an electronic legislative process was begun in The basic intention was to conduct the legislative process electronically from the white paper phase to the stage of promulgation. A legal base was established in January 2004 by amendment of the Promulgation Act. The aim was to simplify and accelerate the legislative process by adopting specific measures: Uniform layout of texts on the basis of macro-supported format models and guidelines on layout. Laying down of a defined workflow. Elimination of duplicate drafts and minimisation of errors. Text management making it possible to compare versions. 96 Light Weight Directory Access Protocol (directory services) 85

86 Publication of white paper proposals and government bills. Legally authentic publication of the Federal Law Gazettes. Obligation to satisfy various requirements during the course of implementation: Use of the electronic signature to guarantee a secure and authentic publication. A facility for subscription to a service for on-demand printouts of individual issues of the Federal Law Gazette must be guaranteed. Shift of responsibility for the layout from the printer directly to the authors. Metadata and texts were therefore separated. The examination of whether the requirements have been complied with is automated. The documents are converted into diverse formats (PDF, XML, etc.). Tabling proposals to the Council of Ministers and handwritten documents must be converted into electronic form before being transmitted to Parliament. The legislative process can be divided into several working stages. After the competent minister has made a proposal for legislation, the white-paper phase begins. On the basis of the comments made during the white-paper stage, the bill is revised and presented to the Council of Ministers. If a decision is adopted by the Council, the Government bill is submitted to the Parliament. Once passed by the National Assembly and signed, the law is published in the Federal Law Gazette. Drafts of a bill prepared by a ministry 1 Internal consultation Decision of the 3 Council of Ministers Government bill (legislative proposal) 2 4 Elektronische Rechtserzeugung Bundeskanzleramt t 5 Process in parliament (independent system) Official publication 9 Server based 8 electronic signature Signing and Counter- 7 signing by President/ Chancellor/Ministers 6 (on paper) Back to the process in the federal chancellery Decision of the National Council (Nationalrat) Source: E-Law, Electronic Legislative Process, Presentation R.Ledinger Broadband Access to the Internet E-government for all is one of the essential demands of the EU s eeurope 2005 Action Plan. All citizens must have the opportunity to use electronic administrative services. Anyone who does not have access to the Internet either at home or in the workplace should be offered access via public terminals or other alternatives. In addition to that objective, the Action Plan focuses on the widespread availability of broadband access 86

87 In comparison with other countries of the world, there is an extremely high degree of penetration of wireless networks offering broadband Internet access in Austria. Why not therefore use these access facilities for e-government? In accordance with an initiative of the Federal Chancellery, 97 working in collaboration with a private provider, it has, since March 2003, been possible to visit all Internet addresses of the public administration with the domain name gv.at free of charge by way of a broadband connection from currently around 350 hotspots. The e-government services provided by the public administration are thus freely available to all users with mobile terminals. Registers Decentralised and federalist organisational structures and competences require a high degree of technical coordination in order to avoid processes being unnecessarily duplicated. The aim is to achieve optimum use of e-government mechanisms. Registers which are used in conducting e-government procedures will be available to all administrative levels participating in the portal group. This will permit access to authentic data contained in the registers and avoid the multiple storage of data. Standardised access to registers offers considerably more advantages: the Register of Company Names, Land Register, Register of Associations, etc. simplify procedures for the private sector. Use of the electronic signature makes it possible to have open systems which can be devised and operated independently of each other. Standard Document Register When dealing with the administration, citizens are often confronted with repeated demands to provide documents such as birth certificate or certificate of nationality. The establishment of the Central Register of Residents (the ZMR) provided an infrastructure which makes it possible to effect a high-quality electronic identification of persons. In the medium to long term, this will replace the use of standard paper documents. The ZMR will therefore be one of the central tools of e-government: The introduction of a standard document register will allow documents to be submitted electronically. Documents required to validate information relating to personal status and citizenship will no longer have to be physically presented in procedures but rather will be obtained electronically by way of a request to the ZMR. In practice, the person concerned can ask the authority to verify the necessary data electronically in the standard document register. This will simplify administrative procedures. Authorities will not have to set up their own register. The ZMR will simply record the accuracy of the registration data in an electronically readable form after they have been verified by the local registration authorities by inspection of the originals. The verification procedure will not entail additional work because it is compulsory to verify identification data by inspecting the documents. The fact that the data is accurate will be entered directly into the ZMR by the local registration authorities. At the request of the person concerned, the accuracy of registration information can be recorded by the registration authority in the ZMR even where no registration procedure is conducted, provided the person presents a document which can serve as proof of accuracy

88 As an alternative to a request by the authority for the standard documents, the presentation of confirmation of residence certificate, 98 in which the accuracy of the data is recorded, can be substituted for the submission of those documents. Confirmation of residence is available in either paper or electronic form. Like the paper version, electronic confirmation has the probative value of a public document because it is signed electronically by the public authority. 99 It is possible to use all the electronically available data entries made by public institutions for the purposes of validating standard documents, where the person concerned so requests. SourcePIN Register The SourcePIN Register for natural persons is a virtual register. The entries are used only when required for the generation of a sector-specific personal identifier 100 and then deleted immediately. A natural person s sourcepin may be stored only on the citizen card. The data processing register is entrusted with maintaining the SourcePIN Register. The SourcePIN Register Authority is the Data Protection Commission since the electronic identification has implications for data protection. The authority s tasks include: maintenance of the SourcePIN Register; conversion of the SourcePIN into a sector-specific personal identifier without the cooperation of the person concerned in cases provided for by statute; definition of the mathematical processes required for calculation of sourcepins or substitute sourcepins and publication thereof; maintenance of the Supplementary Register. The number in the Register of Company Names, the number in the Central Register of Associations or the entry in the supplementary register is used to create the sourcepin of a legal person. These registers are to be set up in the long term. Supplementary Register In electronic procedures conducted by the public administration, the sourcepin is used as a basis for the identification of natural persons and the generation of sector-specific personal identifiers. The sourcepin of natural persons is derived from the number uniquely allocated to a person in the Central Register of Residents. With respect to legal persons, the number of their entry in the Register of Company Names or of that in the Central Register of Associations serves as the basis for calculation. Only persons registered in Austria are registered in the Central Register of Residents. However, in order to enable persons not subject to a duty to register (e.g. Austrians living abroad) to have access to electronic administration through the citizen card, a Supplementary Register will be set up. The sourcepin can then be derived from the entry in the Supplementary 98 See Chapter Basic services, Model Application 99 See Chapter IT Security and Data Protection, Official Signature 100 See Chapter IT Security and Data Protection, SourcePIN und Sector-Specific Personal Identifier 88

89 Register: The Supplementary Register will cover persons who are not registered in either the Central Register of Residents or the Register of Company Names or Register of Associations. The person will be registered either at his own request or, in certain cases, on application by the authority operating the data application. For the purpose of registration, the person wishing to be registered must provide the identification data required under the Registration Act. Legal persons must provide proof relating to their legal advisors and their legally valid name. The purpose of registration is to provide electronic proof of unique identity of the person concerned. Natural and legal persons will be kept in separate sections. For the latter group, authorisations to act on their behalf can also be entered. The detailed provisions governing the Supplementary Register will be adopted in a regulation of the Federal Chancellor. The Federal Ministry of Home Affairs will be entrusted with the maintenance of the Supplementary Register and the calculation of the sourcepins of natural persons. This service will be provided by the Federal Ministry of Finance for all other parties concerned. The rules governing the precise approach to be adopted and the distribution of competence will be laid down in a regulation of the Federal Chancellor after consultation of the Data Protection Commission and in agreement with the Federal Minister for Home Affairs and the Federal Minister for Finance. Persons who wish to approach the authorities but are not registered in any Austrian register are to be identified by means of a recurring identity. Although, in such cases, the person is not uniquely identified, it can be established that it is the same person as approached the authority on a previous occasion. Upon request, the person concerned will be provided with a substitute sourcepin which has been created on the basis of his or her data (e.g. name, date of birth, place of birth, certificate serial number, etc.) and which sufficiently distinguishes him or her. It must be clear that the number is a substitute sourcepin. 89

90 IT FI Identity can be recognized if user signs if id scheme is known BE SE ES... Identities in the EU can be managed automatically by the user Source: R.Posch, Presentation eday Documentation Register Whilst the Central Register of Residents can be used as a standard document register for natural persons, this purpose will be served by the Fiscal Administration Register in the area of self-employment. This Register contains the identity data, divided according to category, of the taxpayer and the nature of the self-employment and professional qualifications. During the procedure, the person concerned may: validate the requisite data himself or herself by submitting the electronically signed report from the documentation register. ask the authority directly to inspect the documentation register electronically. Provided the statutory conditions are met, the data can be obtained through another administrative authority. Register of Addresses The foundations for the establishment of the Register of Addresses were laid by the Buildings and Homes Act (GWR-Gesetz, Federal Law Gazette 2004 Part I, No 9) and the amendment of the Surveying Act (Vermessungsgesetz, Federal Law Gazette 2004 Part I, No. 9). 102 Those acts made it possible to create an authentic database of geographical addresses for the whole of Austria. E-government data applications and other administrative registers can make use of

91 the data contained in it. This means that multiple data enquiries can be avoided. The Register of Addresses is maintained electronically by the Bundesamt für Eich- und Vermessungswesen (Federal Agency for Weights, Measures and Surveys) as a specific register forming part of the land database. An up-to-date and complete database of addresses is thus available for e-government purposes. The Register of Addresses contains geocoded addresses of buildings and properties issued by the authorities. The address contains a variety of information (district, town, street, reference number, cadaster district, property number, etc.). Each plot of land is allocated an address code and each building an address number. The address data are to be provided by the local authorities immediately after issue of the address or change of address. Notification is given via an online application or a standardised XML data interface. The online application for addresses, buildings and homes is made available by the Bundesanstalt Statistik (Federal Institute for Statistics) free of charge. Training applications should make it easier to operate the application easier. A help hotline will be set up for the initial phase. It has been laid down by statute that effective use of the register is to begin on 1 July Certain address data (district, location, street, reference number, plot coordinates, postcode, address code, house number, building coordinates, building function, and address number) can be requested free of charge. This is intended to lead to an intensive use of the address register. It is not permitted to record the results of the enquiry for commercial purposes. A charge is made for enquiries relating to and extracts from the remaining address data. Flat-rate reimbursements of costs will be fixed in a regulation. There is no obligation on the authorities to reimburse costs where they make the enquiry in the course of carrying out the functions conferred on them by statute. There is likewise no such obligation on the Federal Institution for Statistics or fire brigades or other emergency services where use of the register relates to crisismanagement tasks. More detailed provisions on the technical features of the Register of Addresses, its content and structure will be laid down in a regulation. Building and Homes Register The Federal law on the Buildings and Homes Register 103 (Federal Law Gazette 2004 Part I, No 9) provides for the setting up of a building and homes register for statistical, research and planning purposes. The register will be set up and maintained by the Austrian Federal Institution for Statistics. A variety of address and structural data are to be contained in the register: Address data of plots of land, buildings, homes, occupiers, workplaces without premises and buildings and descriptions thereof. The address data for plots of land and residential buildings will be taken from the Address Register

92 The data kept in the Buildings and Homes Register (address data, administrative data, survey data) will be provided primarily by the Address Register, the Central Register of Residents, local authorities and district councils. For statistical purposes, the Buildings and Homes Register will serve as the basic register for censuses based on register data. There will therefore be no need in future to carry out censuses in their current form. Provision is also made for local-authority statistics and reports. Online access will be free for authorities, provided it is for the purpose of fulfilling the functions conferred on them by statute. Local authorities will be able to access all registered data relating to their local authority area. District councils will be granted access rights to the extent necessary for performing their local surveying functions. The Central Register of Residents will have access to residential addresses. The register and administrative data will be transmitted to the Buildings and Homes Register via the online application for addresses, buildings and homes to be made available free of charge by the Federal Institution for Statistics. This is the same application as is to be used for the transfer of data to the Register of Addresses. Persons or entities required to register will therefore have to notify the authorities of their data only once. It is laid down by statute that the Buildings and Homes Register, including the online application for addresses, buildings and homes, is to be set up by 30 June 2004 at the latest. The first entries will consist of data already available (directory of building addresses, statistics on residential buildings, data from the 2001 buildings and homes census and data collected by the Federal Agency for Weights, Measures and Surveys such as geocodes). Central Register of Residents The legal basis for the establishment of the Central Register of Residents was created with the amendment of the Registration Act (Meldegesetz) The Federal Ministry for Home Affairs operates and provides services relating to this data application. The authorities responsible for data protection are the registration authorities. The Federal Institution for Statistics is kept as a joint information system within the meaning of the Data Protection Act The Central Register of Residents is a public register and information can be issued to persons who can prove that they have a justified interest and provide certain data. In electronic communication with the administration, natural persons are identified on the basis of a sector-specific personal identifier. The sourcepin, which is derived from the ZMR number, serves as the basis for the generation of this personal identifier. The ZMR number is allocated to all persons registered in the Central Register of Residents as an unmistakeable identifier. The E-Government Act makes provision for an amendment of the Registration Act in order to take account of the functions of the Central Register of Residents in e-government: The ZMR numbers (contained in the Central Register of Residents) must be made available to the sourcepin Registration Authority so that it can perform its functions Federal Act concerning the Protection of Personal Data (Datenschutzgesetz DSG 2000), BGBl. I No 165/1999, 92

93 Where technically possible, a request for information on registration from the ZMR can be made using the citizen card and the information can be issued by that means. In order to make an enquiry as to a person s principal residence, the interested party must state the first name and surname of and a further piece of information on that person. If a private-sector sspin 106 is given as information, the person making the enquiry must use his or her own sourcepin in order to be able to verify the privatesector sspin. Bodies of public corporations, local-authority associations, judicial officers and social insurance institutions must be permitted to make an enquiry where such an enquiry is necessary to perform the functions conferred on them by statute. The mathematical processes required by the citizen card concept in respect of natural persons are carried out by the Central Register of Residents on behalf of the sourcepin Register Authority. Central Register of Associations The Central Register of Associations (ZVR) has an important role to play in e-government. The E-Government Act permits the use of the ZVR in e-government processes by way of an amendment of the Associations Act (Vereinsgesetz) Like the Central Register of Residents, the Register of Company Names and the Supplementary Register, the Central Register of Associations contains a number (ZVR number), which constitutes an important element of electronic communication between citizens and the authorities. By integrating the register into the portal group system, 108 administrative communication between authorities can be made more efficient since existing resources can then be used. The Central Register of Associations is operated and kept by the Federal Ministry for Home Affairs as an information storage system. The controller responsible for the Central Register of Associations are the association authorities of first instance, which keep certain information (name, ZVR number, date of establishment, seat, representatives and their sspins, etc.) on associations established in their jurisdiction in a local register. The data kept in the local registers of associations is transferred to the ZVR in the joint information system. For the purposes of unique identification of each association, the ZVR issues a ZVR number and communicates this number to the local association authorities. The information on associations kept in the ZVR is processed in such a way that it can be retrieved only on the basis of the association s name and ZVR number. Certain data can be requested online by anyone free of charge if there is no restriction on the provision of the information. The provisions guaranteeing data security (request rights, cautions for staff, technical protective measures to prevent unauthorised access, data migration) are laid down in a regulation. 109 The amendments made to the Association Act 2002 by the E-Government Act relate, essentially, to the ZVR number, register enquiries and provisions on access: 106 See Chapter IT Security and Data Protection, Sector-specific personal identifier. 107 Associations Act 2002 (Vereinsgesetz VerG), BGBl. I No 66/2002, See Chapter Inter-Administrative Cooperation 109 Regulation of the Federal Minister for Home Affairs on the use of association data for the establishment and operation of the Central Register of Associations (Vereinsdatensicherheitsmaßnahmen-Verordnung VereinsDS-VO), BGBl. II No 443/2003, 93

94 Associations must use their ZVR number for external legal matters. This principle of publication means that the sourcepin of an association can be calculated on the basis of the ZVR number. Bodies of regional and public-law corporations are to be granted the right to make online requests for certain data in order to enable them to carry out their statutory functions. The sector-specific personal identifiers of representative bodies and receivers cannot be requested. Public-law corporations can make enquiries only on request. Requests are rejected by administrative notice. The data processed in the Central Register of Associations may be used jointly by the association authorities. 94

95 IT Security and Data Protection 95

96 IT security and data protection play an important role in e-government. Citizens using e-government applications assume that electronic administrative procedures are just as secure and reliable as the classic visit to an office. The public administration is expected to guarantee a high level of data protection and to handle data in a responsible manner. Appropriate measures must be taken in order to ensure that this existing confidence in the authorities is maintained in the context of e-government. Secure online procedures and network and information security are guaranteed by the use of a variety of methods and mechanisms. The modules for online applications, 110 the citizen card 111 containing an identity link, the administrative signature, the sector-specific personal identifier, the use of administrative certificates and electronically signed administrative notices are only some of the means intended to contribute to a lasting improvement in citizens confidence in electronic administrative procedures. Security is increasingly becoming one of the fundamental challenges of our time. Given its increasingly widespread availability, e-government is becoming a critical part of the infrastructure and is therefore particularly deserving of protection. Particular attention must be paid to central components such as registers and directories. Even small-scale attacks can give rise to uncertainty amongst users, which can adversely affect confidence in electronic administrative services. An adequately secure and protected system can counteract such fears and lead to wider acceptance. The use of the international standard XML promotes the separation of processes and decentralised automation. XML and the electronic signature, as well as the mechanisms for securing trustworthiness and data protection which are based on them, therefore make it possible to implement a system of e-government which cannot be attacked at a central point. The administration has an interest in a wide acceptance of e-government because intensive use is directly linked to the efficiency of the applications. In Austria, data protection has had an important status for decades. Unlike the public authorities in other Member States of the European Union, the Austrian administration can look back on a long tradition in the field of data protection. Cooperation with the Data Protection Commission has lead to a data-protection solution for the use of the ZMR number as the basis for conducting online procedures which is satisfactory for all concerned. SourcePIN It must be possible to identify uniquely the person making electronic submissions to the authority. Persons can be identified uniquely by their sourcepin. The sourcepin is stored on the citizen card. It is generated from the ZMR number uniquely allocated to all natural persons resident in Austria. For natural persons who have no Austrian residence, the number allocated in the Supplementary Register is used to identify them uniquely. How to create the sourcepin and sector-specific personal identifier is laid down in the procedural regulation: 112 The CMR number, which is a decimal number of twelve digits, is converted to a binary number. The basis for computation is enlarged using a hash value known to the sourcepin Register Authority. 110 See Chapter Basic services 111 See Chapter Concepts

97 The enlarged binary number is encrypted. The key is secret and known only to the sourcepin Register Authority. The Base64 standard is used to encode the result. The final result is an alphanumeric series of 24 figures: Source: Hollosi/Hörbe, sourcepin-sspin-algorithm V The values are purely examples and not the result of computation Sector-Specific Personal Identifier In order to guarantee data protection, the Austrian e-government system does not use a standard personal identifier. The authorities use different personal identifiers derived from the sourcepin of the natural person concerned and from the relevant procedural sector. This is an irreversible cryptographic derivation which is used only once. This means that the sourcepin cannot be identified from the derived identifier. Similarly, it is impossible to derive a new identifier for another sector from an existing derivation. For data-protection reasons, the sourcepin of natural persons may at no time be stored by the authorities as an identification feature. Where the citizen card is used to sign an electronic submission, the sourcepin is read from the citizen card and, in a fully automatic process, used to derive a sector-specific personal identifier (sspin). The sector-specific personal identifier is computed, by way of a cryptographic procedure, on the basis of the sourcepin and the specific procedural sector 113 of the administration. After a signature has been provided for its area of activity, the sourcepin is no longer available to the authority and it only has the sspin of the person concerned. A series of figures is derived from the sourcepin and the procedural sector and used to generate a secure irreversible cryptographic number which is computed using a particular hash algorithm. 113 Siehe Chapter Guidelines 97

98 If the number is transferred or appears on paper, it must be encoded in accordance with the Base64 standard. Source: Hollosi/Hörbe, sourcepin-sspin Algorithm V The values are purely examples and not the result of computation. Unlike in the case of natural persons, under the E-Government Act, it must be possible to reverse the sector-specific personal identifiers of persons acting as administrative officials. This is intended to guarantee the transparency of governance. In such a case, the sspin can be created only by a request to the sourcepin Register Authority. It is computed by way of a symmetric encryption on the basis of a private key. The result is then encoded. The method of using sector-specific personal identifiers for the purpose of identifying persons can also be used by the private sector for e-business. In contrast to the identifier used for administrative procedures, the private-sector sector-specific personal identifier (private-sector sspin) uses the sourcepin of the controller as the sector code. Therefore, in order to derive the private-sector sspin, both sourcepins are used. This ensures that the private-sector sspin can be generated only with the knowledge and consent of the person concerned. In such a case, it is not possible to read the sourcepin electronically for the purpose of computing the personal identifier but rather it is directly converted into a private-sector sspin by the security layer. Each company or each association has its own sector. If, for the purpose of identification, an authority requires a sector-specific personal identifier from another procedural sector (foreign sspin), the sourcepin Register Authority may make it available only in encrypted form. Only the authority responsible for the sector on the basis of which the sspin was created can decrypt it. Encrypted sspins must be computed in such a way as to make it impossible to trace the person. Encryption is based on the RSA procedure with a key length of 1024 bit. 98

99 Source: Hollosi/Hörbe, sourcepin-sspin Algorithm V The values are purely examples and not the result of computation. Citizen Card as Security Infrastructure Implementation of e-government without IT security measures is inconceivable. The central element is the open citizen-card concept, which is compatible with different kinds of technology and guarantees security for all participants. The security layer guarantees independence of both the system and the applications. By integrating it into the standard browser, it is possible to guarantee security without complicated special installations and complex preconditions. The citizen-card concept is intended to lead to global availability by integrating the administrative signature and other possible data carriers as signature tokens. The secure signature is to be gradually introduced in the long-term. The necessary security components are tailored to the administrative requirements. Their identification is suitable to ensure adequate protection against abuse. The method of using identity links and electronic mandate creates a secure basis for electronic administrative procedures. Insecure password systems and separate registration for each individual procedure will be replaced by the electronic signature, which cannot be created by chance. Before an application is signed, the full text of the application will be displayed. The signature itself requires not only that the person possess a signature tool be it a mobile phone or a signature card. It is also required by law that the person be aware that he or she is about to create a signature. Before entering the PIN code, the signer must confirm that he or she wishes to sign. This satisfies the statutory requirement that the person sign consciously. 99

100 Source: R.Posch, Presentation of Identity link In electronic administrative procedures, the authority must be able to identify uniquely the person with whom it is conducting a dialogue. Existing signature certificates are not, however, sufficient for this purpose as they contain only the person s name. Therefore, the sourcepin (a person s classification key), which is always the same for a particular person, is used as a unique identifier. The identity link is a central component of the citizen card concept. It is a structure signed by the authorities, which links one or more certificates of a person to the sourcepin as the unique identifier. In addition to the sourcepin, the identity link contains a unique identifier for each certificate with which the sourcepin can be linked. The result is a cryptographically secured link between a signature and the sourcepin which makes it possible to identify a person in administrative procedures by automated means. The specification 115 describes the basic XML structure of the identity link and the standards used: The authenticity of the identity link is certified by the sourcepin Register Authority by confirming, by electronic signature, the establishment of a link between the sourcepin and one or more certificates. The signature cryptographically protects the link between the sourcepin and certificate against modification. The signature guarantees the authenticity of the data and identifies the issuing authority by its certificate. The basic XML structure consists of a framework containing the obligatory attributes such as name of the issuer, version number of the standard used, basic data relating to pdf

101 the identity link and the time of issue. In addition, the personal data and attributes for natural and legal persons are defined precisely. The structure also describes the necessary elements of the electronic signature. Encoding specifications make it possible to display the XML identity link in compressed form. Electronic Signature Use of the electronic signature contributes to maintaining the high level of security and data protection in electronic administrative procedures. Thanks to the electronic signature, the authenticity of documents can be guaranteed. Electronically signed documents cannot subsequently be manipulated without leaving visible traces. Electronic signatures also make it possible to identify and authenticate persons communicating electronically with the authorities. It is no longer necessary to identify oneself, as was the case until now, by way of a user ID and a password but this can be done using the citizen card and an electronic signature. The laborious handling of innumerable codes and passwords has thus been consigned to the past. There are a number of practical uses for the electronic signature in administration: forms can be completed and documents created or collected. The essential feature is that the signature is triggered intentionally by the signer by entry of a PIN code. Upon triggering of the signature, the data created are simultaneously linked to the signature. In order to verify the signature, the signature certificate of the signer is needed. The certificate is either sent by the signer at the same time or it can be requested from a publicly accessible directory. The certificate itself is a set of data issued and signed by a certification authority. Signature of the data set ensures in turn that it cannot be altered without leaving a visible trace. If the signed document or the certificate is manipulated, the signature becomes invalid. The citizen-card concept encompasses several forms of electronic signature for the completion of e-government procedures. These are the secure signature, the administrative signature and the official signature. Secure Signature The secure signature is required in administrative procedures in which the identity of the person concerned has already been established but which are subject to requirements that documents be submitted in written form so that the authenticity of the application must be established. More specifically, it is verified whether the person making the submission is indeed the person he or she purports to be. Authenticity is verified in conventional procedures by production of photographic identification or, in the case of a written submission, signature by one s own hand. In electronic communications with the authorities, authenticity is proven by the electronic signature. According to the Signature Act, 116 the secure signature has several characteristics: It can be unmistakeably linked to the signer

102 It makes it possible to identify the signer. The process is controlled by the signer because the signature must be triggered. Subsequent alterations of the data linked to the signature can be identified. A qualified certificate issued, in a manner which can be verified, to a particular natural person. The prescribed security requirements are satisfied. With a small number of exceptions, the secure electronic signature is legally to be regarded as equivalent to a signature by one s own hand. It therefore satisfies the requirements of written form imposed in the Austrian Allgemeines Bürgerliches Gesetzbuch (Civil Code). This is, however, subject to satisfaction of the prescribed security requirements. Administrative Signature E-government is only beginning to be developed. Whilst the necessary components are already available, they are not yet used globally. This is also true of the secure electronic signature, which is not widely used by the population. Therefore, in order to promote the use of the electronic signature in electronic administrative procedures, the administrative signature will, for a transitional period, be regarded as equivalent to the secure signature in the context of citizen-card applications. The administrative signature is intended to lead to unrestricted access to e-government and, in the medium term, to a widespread use of the electronic signature. The administrative signature differs from the secure signature in the signature-creation data and the certificate: Unlike the secure signature, the administrative signature need not satisfy all requirements which must normally complied with when generating and storing signature-creation data for a secure signature. The administrative signature need not be based on a qualified certificate. Despite these more relaxed requirements, the administrative signature offers adequate security. The security requirements were laid down in the Administrative Signature Regulation (BGBL 2004 Part II, No 159), 117 which governs a variety of elements (key length used, impossibility of deriving the keys used in an administrative signature, revocation of certificates, document display, etc.) Official Signature Citizens and businesses must be able to assume that documents issued electronically by the public authorities do in fact come from those authorities and that their content is not forged. Such certainty is to be provided by the official signature. Electronic documents are signed electronically by the authorities before being served on the recipient. The signature can be verified

103 According to the E-Government Act, the electronic signature is an electronic signature within the meaning of the Signature Act, the peculiarity of which is indicated by an appropriate attribute in the signature certificate. The aim is to make documents of authorities more easily recognisable. Official signatures will therefore be used only by the authorities to sign or issue documents electronically. The signature is represented by a logo published by the authority on the Internet in secure form. The serial number, name and country of origin of the certification service provider and the actual signature value must also be stated. Electronic documents printed on paper can be presented as proof, provided that they bear an official signature which can be verified by conversion into electronic form. All information necessary for the reconstruction of the electronic document is to be published on the Internet in secure form by the issuer of the document. Official signatures may take a variety of forms: The documents signed are XML documents which can be reconstructed and which can be displayed in the web browser with the associated style sheet. It is possible to display them in their signed form. The document can be printed. The signature can be reconstructed at any time from the electronic form or from the printed form, provided certain conditions are satisfied. Source: R.Posch, Official signature 118 Combinations of documents and annexes: In the case of annexes that also exist in a different format (e.g. plans, audio documents such as a recording or other formats which cannot be signed) and are attached by the authority to an electronic document, it is appropriate to generate a secure link between these documents to create one unaltered electronic document by means of an electronic signature. It can thus be verified whether the document has been forged

104 Elements of the official signature The official signature will be made visible by a logo. Electronic Authority Citizens who do not wish to conduct online procedures with the citizen card themselves, may ask a representative to do so. In order to act as a representative, a valid authority to do so must be issued by the person to be represented. This is intended to make e-government even more convenient. Particularly persons who are unfamiliar with the new electronic procedures can choose someone trusted by them to conduct procedures on their behalf. The E-Government Act provides the statutory basis: The authority issued, containing the data of the person granting authority and the chosen representative, is signed by the person granting authority and sent to the sourcepin Register Authority. The sourcepin Register Authority can make a web form available for that purpose. Once it has received a valid authority, the sourcepin Register Authority or a body instructed by it will enter the sourcepin of the person being represented, together with a reference to the existence of an authority to represent, in the infobox of the representative s citizen card. The same procedure applies in the case of statutory representation. The sector-specific personal identifier used for electronic submissions made by the representative will be derived from the representative s sourcepin. With the exception of certification service providers and district councils, persons exercising public-law powers may be instructed by the sourcepin Register Authority to verify an authority and make the necessary entry in the citizen card. The person granting authority can limit it to a particular duration or to one or more specific procedures. 104 Where, in the case of professional representation, no particular proof of authority is

105 required, an entry is made, in a form which can be validated electronically, in the citizen card of the representative to the effect that he or she is authorised to act as professional representative. The sourcepin Register Authority transfers the client s sector-specific personal identifier for the relevant administrative procedure to the representative in encrypted form. Encryption ensures that the sspin can be decrypted only by the competent authority. On application, citizens may also instruct specially authorised administrative officials of local or district authorities to file electronic applications based on the citizen card on their behalf. The electronic application is signed by the official s citizen card. The sector-specific personal identifier is derived from the sourcepin of the person being represented and transmitted to the official in encrypted form by the sourcepin Register Authority. The official s general competence to act as a representative can be ascertained from his/her signature certificate. More detailed rules on the technical and organisational requirements will be laid down by regulation of the Federal Chancellor. Source: R.Posch, Presentation of IT Security Handbook Data security is becoming more and more important for e-government. Appropriate measures must be taken to protect the IT systems of the public administration in order to eliminate the risks of unauthorised access, manipulation or technical failure. In order to guarantee data security, not only must the hardware, the software and the data themselves be protected but provision must also be made for organisational and structural security. Organisations must therefore adopt an IT security policy that defines what security measures are to be taken in order to achieve the defined objectives. The Austrian IT Security Handbook 120 is intended to help those responsible for IT matters in the public administration to draw up a reliable IT security policy for their organisation. The Security Handbook contributes

106 to the creation of a standard approach in the field of IT security, without excluding flexibility and independence. The Security Handbook was updated at the request of the Federal Chancellery and published in May In contrast to the earlier version, it is now for the first time available in an XML version also, which facilitates working with the Handbook (specific configurative and various viewing options, checklists and a certain degree of personalisation). Although the Handbook was drawn up for applications of the federal administration, it is also directed at the private sector and other interested parties. It is intended to contribute to the general promotion of high levels of IT security. It takes account of international developments. The IT Security Handbook focuses on security objectives and strategies, organisation-specific IT security policies, security measures, IT security for ongoing operations and best practices. It contains a series of guidelines and recommendations which the Federal administration is obliged to apply in setting up IT security processes. The guidelines are to be regarded as supplementing the existing statutory rules and provisions. The Security Handbook is divided into two parts. Part 1 deals with aspects of IT security management: The IT security policy is intended to ensure the confidentiality, integrity, availability, authenticity and reliability of IT systems. The objectives can be achieved only by continuously monitoring strategies and concepts. The elements of IT security management are a security policy, risk analysis, a security concept, a security plan and security for ongoing operations. 106

107 Development of an organisation-wide IT security policy Detailed risk analysis Risk analysis Approach of basic protection Combined approach Development Drawing up of an IT security concept Selection of measures Risk acceptance IT system security policies IT security plan Implementation Implementation of the IT security plan Measures Promotion of awareness Training Accreditation Operations IT security in ongoing operations Maintenance of the security level Change Management Reaction to events with security implications Source: Austrian IT Security Handbook, 2003 The IT security policy, which applies to all organisations, encompasses rules applying to all areas in which IT is used (Chapter: Development of an IT security policy for all organisations). The specific individual security measures to be implemented are laid down in the IT security policy. In certain circumstances, it may be necessary to develop a hierarchy of IT security policies internal to specific organisations. Part 2 deals with the fundamental organisational, personnel, infrastructure and technical IT security measures: Provision must be made for different levels of protection for the structural and infrastructural security of IT systems (plots of land, buildings, premises). The risk of fire must be minimised by way of appropriate precautionary measures. When changing the use of premises, electric installations must be checked or adapted. Plans of utilities must be kept. When fitting equipment and storing supplies, account must be taken of certain security matters. Among the most important measures regarding personnel are rules for staff, the use of external workers, safety training programmes, incident handling, supervision of users 107

108 and staff training. The establishment of an IT security management process, an IT security policy covering all organisations, a system security policy, defined areas of responsibility, rules on the separation of functions, standard work stations and the setting up of accredited IT systems are intended to achieve a satisfactory level of security. IT security for the entire life cycle of an IT system (product selection, system development, design, etc.) should be the goal. Organisational and technical measures are intended to guarantee that access to IT systems, networks, programmes and data is granted only to authorised persons and processes. The system and network administration must be supported by appropriate tools. IT security must also be guaranteed with regard to ongoing operations. The areas of responsibility must be defined in the IT security policy. Any precautionary measures should avoid causing disturbances. It must be ensured that the most important applications and IT systems continue to function for a certain period in the event of a system failure or disturbance. Provision should also be made for damage limitation in the event of a disaster or emergency. The Austrian IT Security Handbook is regularly revised and updated. Feedback can be given and experiences related to the working group. 121 Virtual Private Networks (VPNs) The purpose of a VPN is to ensure that sensitive data can be transferred in a trustworthy way via different networks (LANs and WANs, 122 private and/or public networks) the technical security of which cannot be assessed. This means that only organisations or persons authorised to do so can access the data to be protected and alter the information they contain. Rules on the trustworthy transfer of sensitive data via different networks the technical security of which cannot be assessed and on rights of access of authorised organisations and persons to the data to be protected are to be laid down in a VPN policy. The ICT Strategy Unit provides information on the basic standards of VPNs and security matters: 123 The advantages and disadvantages of public and closed communication networks are compared. The features of various kinds of VPN are described (redundant site connection through a tunnel via the Internet, connection between foreign sites or users via the Internet subject to certain security precautions, connection between differing technologies, Wide Area Network: the various components of such a network are located at great geographical distances from one another. The computers are linked by various lines (e.g. telephone line)

109 connection using dial-up nodes of the ISP 124 ). When selecting a VPN, fundamental decisions must be taken as to the system, additional functions, manufacturer and performance. Defined assessment criteria are helpful in making such decisions. Security Levels SSL Session > 100 BIT-KEY dns.name (Server) Server Cert Identified phase DATE & TIME Dns.name Server resp. Gateway Benefits Adaptable confidentiality Easily incorporated Layered technologie Confidentiality classes I Confidential (SSL > 100 Bit) II Highly confidential (signed tokens) (download) III Confidentiality requiring authentication (server certificate verified) (installed) Secure communication over open networks is achieved by complying with the relevant security level to be applied according to the confidentiality requirements. In addition to the security classes of the portal group, security levels were defined: 125 Security level I Here, there is no particular need for security. Citizens or businesses interact with the administration. Communication takes place by way of a server-authenticated connection of a key length of 100 bit and a certificate with an administrative attribute. Level I is appropriate in the case of access to information which is not subject to a duty to maintain secrecy or data-protection requirements. Security level II Security level II must be complied with in the case of secure communication in administrative procedures. It is clear to the user and to the server who is communicating with whom. The 124 Internet service provider 125 Security levels applying to citizen-authority communication in the field of e-government, 109

110 client is identified and authenticated by the citizen card. The rightful holder of the citizen card consciously triggers the electronic signature using the citizen card. Security level III Signature certificates at both the client end and the server end achieve identification, authenticity and confidentiality. The direct integration of the certificates into the connection protocol allows the server identity to be verified automatically. Both certificates are protected against technical manipulation by the use of security modules (e.g. cryptoboxes). Security level III is to be complied with when transmitting sensitive data. Security Classes in the Portal Group Security requirements may differ from application to application. The degree of security necessary is determined by the data to be processed. The security measures taken by the user and the operator must take account of various factors. Spatial and physical security, authentication security, network security and training to make personnel aware of the issues are just some of those factors. The security requirements at the user end are satisfied by the base portal in the portal group. The definition and representation of security classes in the portal group enables an application to verify whether a user satisfies the security requirements necessary for use of the application function. A distinction is drawn in the portal group between four security classes numbered 0-3. They are described in the specification SecClass , ordered according to their field of application: IT systems which fall in a low to intermediate protection category are classed according to the Data Protection Act. A detailed risk analysis is not carried out. Applications are categorised in four security classes (freely available information, request for personal data which are openly accessible such as registration information, transactions with personal data and transactions with sensitive data). IT systems which require a very high level of security protection are subject to a detailed risk analysis. The level of the need for protection is determined according to the circumstances (infringement of law, interference with personal integrity, confidentiality, etc.). From a user s point of view, the factors determining the security class include devices, network connection, location or authentication with knowledge. The security requirements, which must be defined by the relevant users organisation, are graded from anonymous to authenticated. If authentication is required, the security class depends on how authentication is triggered (UID/PW, knowledge and possession or biometric feature or knowledge and possession in the protected area). Data security can be graded (from genuine to strict encryption). When registering, staff must identify themselves with photographic identification. If the application requires a higher security class than the user is permitted to enter by the base portal, an error message is received. A connection is established between the application portal and the base portal on the basis of a server authentication by a certificate (for HTTPS) or a signature. Data security

111 is guaranteed, depending on the applicable security class, by protocols, signature, encryption or transaction confirmations. X.509 Certificate Enhancement X.509 certificates are used to protect electronic communication channels and the electronic signature. They permit the integration of additional attributes in the form of certificate enhancements. The certificates are issued by a trusted authority. They confirm the unity of the key pair and attributes linked to the certificate (name, purpose, etc.). In order to distinguish a certificate of the public administration, the administrative certificate is given an additional attribute. The X.509 certificate enhancement for the administration describes the specific enhancement mechanism 127 and the administrative attribute (object identifier of the public administration). Such specially marked certificates facilitate the management of identities and roles. International Standards The aim of interoperability and open interfaces can be achieved only by using international standards. E-government applications are therefore based on standards such as XML, SOAP und standard protocols such as SSL, TLS and IPSec

112 112

113 Specifications 113

114 Internationally accepted formats and standards, in particular XML, 128 must be used in communications between the public administration and its customers. XML is an internationally accepted and widely used computer language utilised to describe complex data structures. Using XML promotes the interoperability of e-government applications. The specifications used are based on these standards. The publicly available interface definitions facilitate efficient web communication and support the strategic open source approach. Instead of proprietary partial solutions, interfaces permitting the integration of back office applications are jointly defined. Personal Data The first XML specification was the personal data structure, 129 which was drawn up jointly by the federal, regional and local authorities in January The personal data record serves to describe persons uniquely and is used in all e-government processes concerning persons. The XML specification describes the information cluster of the personal data structure. In order to satisfy the specific requirements of applications, an identification type was introduced which is able to represent various expressions of identification data. Since not all elements must be used, it is less a data model than an information model. Applications based on the XML structure can derive, restrict or enhance these data according to their needs: Standard types 130 were used for type definition (xs:anyuri, xs:string, xs:token). In accordance with XML standard, the information in the personal data structure is in unicode. Applications should support encoding in documents (ISO , ISO , UTF-8). The information cluster used to identify the person consists of several identification features (value, type of identification, competent authority responsible for the value and type and additional information). The generic concept person used for natural and legal persons contains elements common to both structures. It can be used in other schemas as a stand-in for the concept of natural or legal persons. The element containing the personal details defines the name, alternative names (e.g. stage name), marital status, sex, birthplace, date of birth, nationality, etc. The identification element for legal persons contains its classification, full name, alternative names, organisational form according to X.500 definition, etc. The generic address element describes the identification features of the address, group definition and identification type. The identification cluster for addresses contains the specific address and permits categorisation according to geographical and functional criteria. 128 Extensible Markup Language html 130 W3C XML-Schema Part2, Definitions of HR-XML Consortium and XML-Signature Syntax and Processing W3C-XMLDSig 114

115 A further element contains the specific telephone number and permits its categorisation. The structure for Internet addresses is defined. It permits the administration of certificates for encryption and signature purposes. The information cluster of the signed data structure contains information blocks of associated material (person, address, signature). Data not contained in the elements can be added. The equivalence list 131 of the personal data structure contains a German description of the various identification elements. Documentation on the XML specification can be downloaded in a packed format. 132 Security Layer The security layer is the XML interface 133 via which a procedure (application) can communicate with the various elements of the citizen card environment (creation of electronic signature, reading of infoboxes, etc.). Communication follows a straightforward pattern: the application sends a request to the citizen-card environment, which then responds. The request-response mechanism is based on the XML standard and is combined in a protocol. The protocol consists of a series of interface commands. The individual protocol elements are combined in an XML schema (Core-1.2.xsd). 134 The names of the elements were drawn up on the basis of a names convention. For the purpose of generating the signature, two signature formats must be supported (CMS, XMLDSig). Unlike the CMS standard, XMLDSig signatures can be used to sign several data objects. In the case of CMS format, the request for verification of the signature contains information on the signer, the signature to be verified and, in some case, the time of signature. The response to the request for verification contains information on the X.509 certificates of the signer (name of the signer, name of the issuer, serial number, etc.). The validity of the signature is verified using a signature attribute containing metadata relating to the signed data object. In the case of verification of signature data in CMS format, each link in the certificate chain, from the signature certificate to the trusted root certificate including a status check for each individual certificate, is constructed. If all the certificates are valid at the time of verification, a certificate chain can be created. In the case of XMLDSig format, the denominator for the key used for the signature is given in the signature request. The request carries a container for each data object signed. The container is filled with information required for production of the signature and the display in the trusted viewer. An attribute provides information as to whether the data object can be directly enveloped in the signature structure or whether the signature should be detached from the data object. If the signature is to be enveloped in an existing XML signature document, the request carries an additional container holding signature information. If it does not carry such a container, the signature may not be enveloped anywhere. The response to the signature request contains the encoded electronic signature. If the signature has been enveloped in an XML document, the response contains the document into which the signature is integrated. All implicit transformation parameters are combined in a single signature manifest. The signature itself contains signature attributes (ETSIXML) which describe

116 the signature (metadata on each document to be signed, certificate reference, certificate chain). In the case of CMS signature verification, the request to the citizen card environment contains information on the signer, signature, time of verification and the signed data object, provided that object is not also encoded. The response delivers information on the X.509 certificate of the signer (name of the signer, name of the issuer, serial number, certificate enhancement in the case of a qualified signature, results of the signature verification and verification data). In the case of XMLDSig signatures, the signature verification request contains information on the signature to be verified (XML document with directly enveloped signature and signature path) and, optionally, the time of verification and supplementary objects. The response includes information on the public key of the signer and the results of verification of the signature, signature verification data, the signature manifest and any further manifests. The citizen card contains infoboxes. The citizen card environment takes appropriate measures to protect access to these infoboxes. 135 The security layer permits access to the data in a variety of forms (request, read, write access). A distinction is drawn between two types of infobox: binary file and associative array. The binary file can only be read. An associative array permits reading and writing. Different access options are permitted depending on the type. An application sends a request to the citizen card environment for information on which infoboxes may be accessed. The response contains information on all accessible infobox denominators. The security layer provides applications with encryption facilities. In order to encrypt a communication, a symmetric secret key can be created using an asymmetric code. This entails encryption of a temporary key, which is then used to encrypt the communication. Applications can request information on properties of the citizen card environment and on the status of the citizen-card tokens (supported signature transformations, display formats, protocols, connections to transport protocols, 136 etc.). Standardised key and infoboxes 137 can be selected via the security layer. If there is a malfunction in the citizen-card environment, the application receives an error message in response to the request. The error codes are described in a separate document. 138 All errors which have been notified since Version have been collected in summary report Implementation of a security layer necessitates certain interface commands as a minimum requirement of the citizen-card concept: Signature profile: the citizen-card environment must able to create and verify all three XMLDSig signature types (detached, enveloping, enveloped signatures). Likewise, it must be possible to execute and verify signature manifests. Defined algorithms are required for the purposes of computation, canonisation and transformation (RSA, DSA, ECDSA, SHA-1, C14N, C14N with comments, EC14N, EC14N with comments, Base 64 Decoder, XPath Filter 1 and 2, Enveloped Signature, XSLT). The citizen-card environment 135 Siehe Chapter Concepts, Citizen Card

117 must also be able to cope with individual child elements of X.509-based code information. At least the protocols HTTP, HTTPS, LDAP and relative URI must be supported in the breakdown of URIs. Additional protocols are recommended. The interface protocol security layer must be linked to defined TCP/IP and HTTP transport protocols. It is also recommended that there be a link to SSL/TLS and HTTPS. All relevant documents can be obtained on the citizen card website at Standard Display Format SL Applications must be able to use the commands of the security layer interface without having to know the citizen-card environment. This is dependent on there being at least a display format that can be processed and displayed by any citizen-card environment. The standard display format SL specifies requirements which must be fulfilled. In addition, it defines restrictions which guarantee a secure display. The specifications are based on the international standards XHTML and CSS : The instance document and display command are defined in the concept definition. The profile description for the XML structure of the standard display format sets out the restrictions as compared to the XHTML 1.1 standard (attribute collection and modules). The restrictions are combined in the form of an XML schema. The XML schema can be downloaded in packed form. 143 The CSS 2 profile defines minimum requirements for the syntax which the citizen-card environment must be able to process when displaying documents. This includes the integration of CSS formats into the display format, the application of these formats by the citizen-card CSS selectors and CSS attributes. Pictures can be integrated into the standard display either as an image or as list symbols. The pictures are not directly enveloped in the instance document but must be referenced by way of a URI. The referenced image data are incorporated, together with the instance document, into the XML signature as additional data. The default CSS style sheet 144 is a defined component of the standard display format specifications. MOA ID Persons who communicate with the authorities electronically identify and authenticate themselves with their identity link and electronic signature, which form part of the citizen-card

118 concept. 145 The basic module Identification (MOA ID), which is one of the modules for online applications, enables applications to delegate identification and authentication. The function of the MOA ID is to support applications in establishing a secure link between users and a sector-specific personal identifier 146 or other user-specific data (authentication of users using the citizen card and security layer, configuration of the MOA ID). The MOA ID consists of an authentication component and a proxy component. Both components communicate with the user s browser and the online application. Communication with the user s security layer takes place both via the browser and directly. The authentication component transfers the registration data to the proxy component following authentication of the user. The proxy component accepts the data and completes the log-in process in the online application. Communication between the user and the online application takes place via the proxy component. Both components can be used on different computers. The log-in and log-out process is effected in several steps: 1. The user connects to a web portal in order to access the desired online application. 2. The link to the online application refers to the authentication component with which the user is connected via HTTPS. 3. In order to read the identity link, the authentication component generates an HTML site, which is sent to the browser. 4. The browser sends a readout command to the security layer by HTTP POST. 5. Once it has received a response from the security layer, the authentication component transmits to the security layer a request to sign the AUTH-Block generated by it. 6. The signed data are transmitted back to the authentication component and verified by it. The user s log-in data are registered. 7. Following successful authentication, a site for redirection to the proxy component (SAML Artifact) is generated and sent to the browser. 8. The browser directs the proxy component through. The proxy component can use the transmitted unique SAML Artifact to request the log-in data from the authentication component. 9. Once it has received the log-in data via SOAP, those data are deleted in the authentication component. 10. The proxy component reads the configuration file containing the description of how the data are to be transmitted and logs the user into the application. 11. The proxy component then carries out the data exchange between the user and the online application. 145 See Chapter Concepts, Citizen Card 146 See Chapter IT Security and Data Protection 118

119 1 Portal 2 Browser MOA-ID Authentifikationcom ponent 4 5 MOA-ID Proxycomponent 2 6 MOA- Signatureverifik ation Online- Applikation Application Security- Layer Citizen-Card Source: R.Schamberger/ L.Moser, Specification MOA ID, 2002 The MOA ID specification 147 defines general requirements for platforms, interfaces, etc.: TLS authentication for all interfaces between the components and applications. Scalability and round-the-clock operation are compulsory. All defined XML elements are attributed to a defined namespace. The authentication component is activated by online applications via an available URL in the user s browser (HTTP request). The user can establish the authenticity of the authentication component (signature and certificate path to root certificate) via a TLS protocol. Element and value of the request for an identity link made by the authentication component are defined precisely. An interface defines the XML response site to be created for the purpose of signature of the AUTH-Block by the security layer. The interface through which the activated online application can be accessed is described by the HTTP request for activation. The AUTH-Block data structure containing defined information (first name, surname, URLs, etc.) is created on the basis of XSLT style sheets. The log-in data are represented in the form of an SAML assertion and contain data such as the signed identity link, sector-specific code, certificate type, etc

120 Precisely defined data must be configured in order to communicate with all mechanisms implemented in the security layer. MOA SP and SS The modules for online applications include, in addition to the module used for identification and authentication of persons, a module for signature verification (MOA SP) and for the creation of a server signature (MOA SS). MOA SP provides the signature verification functionalities required by online applications. Both signature types in the security layer are supported (XMLDSig and CMS signatures). MOA SS encapsulates all functionalities necessary for the creation of a signature by the server. XMLDSig signatures and signatures conforming to the security layer are supported. Both modules are set up as shown below. Source: R. Schamberger/ L. Moser, Specification MOA SP und SS, 2002 The general requirements to be met by the MOA SP and the MOA SS are laid down in the specification. 148 The aim is to find solutions which are not dependent on platforms: Authentication is carried out via TLS. Scalability and round-the-clock operation are essential requirements. Logging facilitates the search for problems and errors

121 All XML elements are attributable to a defined namespace. The signature verification module makes it possible to verify XMLDSig and CMS signatures. The requirements to be met by interfaces, certificate formats, message formats, etc., in respect of both signatures are defined precisely. The MOA SS makes it possible to create simple signatures in XMLDSig format in accordance with the security layer specification. When a signature is created, a signature key is selected from a group of private key. If that key is still valid, the signature is created. The MOA SS can be accessed via an interface based on SOAP or API. The module must make precisely defined configuration options available (client applications, CSP, TLS authentication, import of private keys, administration of certificates, profiles, algorithms, etc.). A modular structure must make it possible to use different signature creation and verification components. Identity Link The identity link is an integral part of the citizen-card concept. It is a data structure which links a person s signature certificates to that person s identity in a manner that can be verified automatically. The sourcepin Register Authority confirms the link between the basic concept and the cryptographic keys and secures the link, using its signature data. The issuing authority is identified on the basis of its certificate. Persons communicating with the public authority in the context of an electronic procedure can, through use of the identity link, be uniquely identified on the basis of an identification key (sourcepin). The person retains the same PIN throughout his or her life. The various elements of the identity link for natural persons are specified in the XML definition of the identity link. 149 The XML framework structure is based on the SAML standard. 150 It consists of compulsory attributes (SAML version number, date of issue of the identity link, name of the issuer, etc.). The basic data contained in the identity link (personal data and the person s public key) and the electronic signature of the issuer conforming to the XMLDSig standard 151 are likewise to be integrated into the framework structure. Certain rules on encoding must be implemented for compressed representation. As a result of the limited memory available on the citizen card, it is recommended that the identity link be compressed. Since a large part of the identity-link structure is based on known and defined values, which can be recreated at any time, compressed storage is entirely feasible. The compressed data memorised contains the variable elements and a URL which refers to an XSLT style sheet of the identity link. The style sheet contains the entire XML structure of the identity link, to which the variable elements can then be added. The URL of the style sheet should be no longer than 48 symbols. The encoding of the compressed data in the memory is represented by an ASN DER encoded string. For the purpose of implementation on the basis of style sheets, the compressed format is converted into an XML file TU-T Recommendation X.680 (1997), ISO/IEC : 1998, Information Technology Abstract Syntax Notation One (ASN.1), Specification of Basic Notation 153 ITU-T Recommendation X.690 (1997), ISO/IEC : 1998, Information Technology ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) 121

122 EPS 2 E-Payment Standard Electronic procedures may entail costs for the person making the submission. In order to effect a complete transaction, secure methods of payment must be offered. The electronically signed confirmation of payment makes it possible to integrate payment directly into online procedures of the e-government system. The e-payment confirmation system was devised together with the inter-bank Studiengesellschaft für Zusammenarbeit im Zahlungsverkehr. 154 The EPS 2 e-payment standard is an open standard interface for online payment systems but is not an independent product. It is supported by all Austrian banks participating in the electronic payment system (EPS) and functions on the basis of the Internet banking system of the relevant bank. This standard can be integrated into applications of the public administration and of the private sector. The essential foundations of the EPS 2 e-payment standard 155 are the ECBS banking standard 156 for the electronic payment initiator, the first version of the EPS e-payment standard and the electronic confirmation of payment for e-government. The interface specification lays down the technical requirements for the data exchange: A basic data container for the settlement of online payments is defined. The XML structure is described in a schema 157 based on the W3C 158 standard. Exchanges of communication are based on HTTP and HTTPS protocols. Security is ensured by a session time out. After a defined period of time, the connection between the bank and the customer is severed. All URL information required to carry out the EPS process are transmitted to the bank. The URLs must be encoded according to UTF-8 by the public authority (handler). Encryption with an SSL certificate is recommended for communication between the handler and purchaser. The handler s request is based on HTTPS (SSL/TLS). Communication between the bank and the handler is exchanged on the basis specified by the handler. The data container for the payment request comprises several data containers (handler-bank payment order, electronic confirmation of payment for the handler, receipt of the electronic payment confirmation, integration of external data containers for national requirements). The data containers are technically combined in their own unique namespace: The payment order contains all the data required for the settlement of payment and for categorisation of successful payment by the recipient. These data correspond to the information on a printed payment slip. Additional information on the transaction which cannot be represented in the EBSC EPI standard can be integrated via an external data container (AustrianRulesDetails)

123 Certain data elements are defined in the data container for the bank s electronic confirmation of payment to the handler (content, bank signature with X.509v3 certificate). Once it has received confirmation of payment, the handler transmits confirmation of receipt to the bank. The values received by the handler are sent back to the bank. Payment can be divided into a number of stages: The purchaser selects a bank. The handler generates a payment request and transmits it to the relevant bank. The handler transmits an XML message to the bank (XML schema) and opens a session. In response, the bank sends an XML message containing defined data elements. The purchaser (citizen) who is still at the start of the payment procedure in the form is directed to his or her online banking system. Following entry of the TAN, the application verifies whether the connection to the handler s web shop is still active. Before transmitting the confirmation of payment to the handler, the bank carries out a vitality check to verify whether the connection to the handler s application is still intact. If the connection to the handler application has been interrupted, the purchaser receives an error message. If the vitality check is positive, the money is transferred and the payment confirmation is transmitted to the handler. Three transmission attempts are made. The handler informs the bank of receipt of the payment confirmation. The bank redirects the purchaser to the authority (handler). The bank s payment confirmation is signed. Explanatory information on the signature profile for e-government is available from STUZZA. In the event of an unsuccessful transfer or cancellation of the transfer, the citizen is directed back to the form. Where the notification of payment given to the bank by the handler or the confirmation of payment sent by the bank to the handler is to be signed, a defined signature profile 159 must be used. The signature profile describes: XML namespace prefixes. Requirements which must be met by a trusted certification authority. An example of a signed payment request and payment confirmation. In order to facilitate implementation, model protocol messages 160 for EPS2 are available. Electronic Delivery A complete online transaction is impossible without an electronic delivery system. Citizens approaching the administration by electronic means expect electronic replies. These are provided by an electronic delivery agent, which ensures that documents from the public authority are sent to citizens in a verifiable manner

124 The delivery specification 161 serves the exchange of data and information between authorities and the delivery agent. The principal information requirements for the delivery are the recipient, the document to be served and organisational data and attributes intended to secure data integrity. The structure has been defined as optional as possible in order to allow combinations. Not all the elements need necessarily be used. It is therefore more an information than data model. Generally, the data structure is based on standard types and definitions of the W3C XML schema Part2 and definitions of the XML signature syntax and processing (XMLDSig). In justified cases, special types and elements were defined. The basic XML structure serves as an envelope for the individual information clusters. The actual application data (elements of administrative notices, etc.) are intended to act as stand ins. The delivery data can generally be signed. Nevertheless, the data in notices must be signed. The individual functions are defined in the specification. The identification type describes a variety of identification attributes. Particularly characteristic is the document identification attribute (value of identification, type, issuing authority, additional attribute). The information cluster of delivery data defines the document identification of the delivery container, the delivery service, the metadata (quality requirements such RSa, date of dispatch, time stamp, date of notification, recipient for confirmation purposes, etc.), validity, notification element and documents to be delivered in XML or another data format. The delivery confirmation contains the related information as to whether or not delivery was successful. The actual delivery data are not retransmitted but are referenced. If the delivery agent fails to collect a document, the sending authority is informed by way of retransmission of the data. Communication Structures Electronic delivery is carried out in accordance with a two-layer protocol. As a first step, a request is sent by HTTP-Get to the delivery centre for information as to whether the recipient is registered with a delivery agent. The data are represented internally in a directory of the delivery agent and can be requested by way of an LDAP protocol. As a second step, communication is exchanged with the recipient s delivery agent. This communication between the sender and the delivery agent takes place via an XML interface. The structure and requisite specification profiles for the individual XML messages are described in the specification. 162 The interface is composed of several specifications: SWA 163 makes it possible to transport SOAP messages containing additional information in the form of attachments. These may be used where binary files such as PDF or ZIP are sent. In the case of encrypted content, the encryption container can also be delivered as an attachment SOAP with attachments 124

125 SOAP creates the envelope the data on use. The message itself is contained in the SOAP body. ZUSE 164 contains the basic data for delivery (quality of delivery, time-limits, etc.). The delivery process entails three messages (send document, send proof of delivery, send notice of impossibility of delivery). Where encrypted data are sent, the S/MIME standard is used, which itself is based on the CMS standard. 165 The sender encrypts the document in accordance with S/MIME. 166 The data are transferred as an attachment. The delivery agent accepts the data. During the collection process, the delivery agent must offer the data to the user as an RFC S/MIME message for downloading or forwarding. The data can also be offered in their original form as a CMS data file. Delivery Directory Schema In the context of the electronic delivery, a directory is used for the purposes of information distribution. The directory provides the sending authority with information on the recipient. A person may be registered with several delivery agents. The specification of the individual elements of the LDAP directory model 168 is based on the Standard Lightweight Directory Access Protocol (v3). Each delivery agent keeps a directory. All directories are connected online to a central service (delivery centre), which provides the information requested by the sending public authorities. However, the central service merely refers the authority to the specific directory with which the recipient is registered. The central service itself does not have information on recipients at its disposal. Where a request is made, the central directory service provides information on the relevant delivery agent, associated encryption certificates and any absence of the recipient. In the case of natural persons, requests can be made in a variety of forms (request with delivery on the basis of the sspin, delivery on the basis of the name, name and address for notification). Replies to requests can also take a variety of forms (hit, no hit, minimum information, optional supplementary data). In the case of legal persons, the request can be made using the sourcepin or the name and address of the person. Replies are given in the same forms as for natural persons. Objects are represented according to their classification in the Directory Information Tree (see diagram). 164 Delivery model 165 Cryptographic Message Syntax 166 Secure Multipurpose Internet Mail Extensions 167 Internet message format

126 Organization (dc=at) OrganizationalUnit ou=natpers ou=jurpers gvnatperson gvjurperson Source: M. Liehmann, Electronic Service of Documents, LDAP Schema description, 2004 The object category natural persons defines the personal data. The attributes of legal persons are described in the category legal persons. Further categories are requestauthorised sender and geographical information. LDAP gv.at The portal group 169 is an aggregation of joint administrative portals which make their applications available to their portal group partners. The task of administration of the users entitled to use the applications is decentralised and is carried out by the organisation (base portal) to which the user is attached. Rights are granted by the application portal. Objects of the public administration (local authorities, regions, Federal Ministries, self-governing bodies, etc.) are recorded in the ldap.gv.at directory. The LDAP-gv.at specification 170 describes the object categories of the federal administrative system (organisation, organisational unit, personnel, user rights). An internal LDAP structure or an RDBMS 171 may be used as a source of data. The directory contains the information on users, applications and rights which is relevant to the portal. Information on internal objects and attributes of the portal such as data on login administration, authentication on the basis of X.509 certificates or trusted connections to external portals is not included. The LDAP directory has been devised as a distributed service with common root nodes (DITRoot gv.at or.at). Denominators and list values are defined in English so that experiences can be exchanged throughout the European Union. The first part of the schema includes the data required for the authentication of users. The second part describes the data for authorisation and navigation. The definitions explain the concepts of organisation, application, staffed organisation, organisational unit, official, function, directory operator, application owner, application administrator, user administrator, rights administrator and application rights. Objects are positioned according to their classification in the Directory Information Tree (DIT). Any staffed organisation with rights to access the application has its own root entry. 169 See Chapter Inter-Administrative Cooperation Relational Database Management System 126

127 The organisation (domain) with the power to appoint and dismiss staff is legally responsible for user administration. A natural person can be classed under several organisations. Where a person (gvorgperson) has several entries, these are combined in a global identifier. Source: R. Hörbe, Specification LDAP-gv.at, 2002 If a person belonging to an organisation performs different functions carrying different rights, the rights are linked to the person s functions (gvpersonfunction). Where persons are classed under several organisational units, the classification of their functions must be entered in the data element gvorgperson as an attribute. Objects are linked to their category (RID) in a structured fashion. Source: R. Hörbe, Specification LDAP-gv.at, 2002 No matter how complex the internal hierarchy of an organisation, rights references are to be broken down until only objects in the categories gvorgperson or gvpersonfunction remain. A flexible data structure ensures that it is possible to delegate rights. Various objects may be granted application rights. These are represented in the data elements by attributes. Access rights are defined in the object gvuserrestriction. Additional attributes and value keys are defined for any further restrictions. X.509 Certificate Enhancement X.509 certificates are used to protect communication channels and the use of electronic signatures. The certificates are issued by a certification services provider or another trusted source. They confirm the link between a cryptographic pair of keys and attributes (purpose, 127

128 name, identifier, etc.). X.509 certificates used by the authorities are distinguished by administrative attributes. 172 This certificate enhancement makes it easier to manage identities and roles: The structure of X.509 certificates is defined by the RFC3280 standard. The binary code ASN.1 DER is used to store data. Each enhancement has a unique denominator, a flag indicating whether it is critical and its actual value. Applications must recognise critical enhancements. Certificate enhancements of the public administration are not marked as critical in order to ensure that processing can be carried out with standard components. At present, the object identifier (OID) is defined as the certificate enhancement of the public administration. The object identifier makes it possible to establish a link between a certificate and an administrative unit. If there is no known administrative identifier, only an administrative attribute will be shown in the certificate. Where there is an administrative identifier of an administrative unit, a directory string is used. This guarantees the best possible compatibility with existing applications. OID of the Public Administration Object identifiers are unique codes for objects which can be recognised worldwide. Objects are recurring, precisely defined information, definitions or specifications. Standards for their use are laid down in ISO/IEC The object identifier makes it possible to identify uniquely the signature and server certificates of the public administration. The structure of the OID tree of the Austrian administration is described in a specification: 173 Administration of OIDs is decentralised. The OID gv.at is administered by the ICT Strategy Unit. Applications must be addressed to this unit (numbering@cio.gv.at). OIDs are issued only to public-administration bodies and not to individuals or the private sector. All bodies entitled to use the domain gv.at are authorised to use an OID. The body itself administers the branch of OIDs issued. The root OID is Only OIDs beneath that root OID are issued to administrative units

129 The OID tree has the following basic structure: Administration AT Experimental.1 Organisation.2 Services.1 General.others (e.g. BMI).1 Verzeichnis.3 Security.2 Communication Source: A.Hollosi, Object identifiers of the public administration, 2003 The registered object identifiers (experimental branch for test and pilot projects, organisations, services, etc.) are listed in a table. Certain specific object identifiers are described in detail. Metadata Online information provided by the public administration must satisfy certain quality criteria. Metadata help to fulfil these quality requirements. The standard supply of information to providers of information services is governed by associated metadata such as validity, contact for enquiries, permission to disclose, etc. A temporary structure for online information has been developed in cooperation with the Wiener Zeitung newspaper. 129

130 130

131 E-Government Open Source Programme and Tools 131

132 The organisational units entrusted with the implementation of e-government acquire, in the course of their activity, extensive technical and organisational knowledge. The experiences gained in developing and adapting open source can be documented and made freely available. This contributes to attaining one of the objectives of eeurope, which is to facilitate the implementation of the new media and technologies for public and private bodies which have only limited means at their disposal for the use of ICT. In recent years much experience has been gained and much software has been developed for the Austrian system of e- government with a freely accessible source code. The specifications developed can be used, subject to the conditions of their respective copyright notices. If the specification is modified, the modification must be clearly marked. Any enhanced specification must be made freely available. Security Capsule The security capsule 174 is a prototype which can be used to illustrate the operation of the security layer. The prototype contains software of the Apache Software Foundation (Xalan, Xerces) and of the IAIK 175 (JCE-Provider, ECC-Provider, CMS-Package, XMLDSig package). It serves solely test, research and development purposes and is not a secure product within the meaning of the Signature Act. The prototype is based on the security layer specification of 25 February A version which already implements parts of version 1.2 of the security layer specification is available. 177 The prototypes are not intended for daily use or use in normal cases but rather as a reference and test environment for developers or as an example for the replication of citizen-card environments. Test Mail Service The test mail service 178 makes it possible to check whether the systems used are compatible with the standards and minimum response times laid down by the policy. Any deviations from the required performance of the mail client can be identified. Specifically, encrypted, signed and clear-text mails are generated and sent to a selected recipient. The service is provided free of charge by the ICT Strategy Unit. Form Converter In January 2002, the ICT Board decided to make an XML form converter available to link electronic signatures to conventional web forms in a standardised form. The aim was to lay down a standard for back ups of the entries. The converter was created by the ICT Strategy Unit together with the regions and is available as a model application. 179 Using the form converter Web2XML, existing web forms can be configured with minimum effort so as to allow signature of the data contained in the form

133 WLAN Test Installation In September 2002, a WLAN test installation was carried out in the premises of the ICT Strategy Unit in order to test the WLAN strategy. The wireless LAN is available to all visitors for the duration of their visit. To begin with, it will be accessed with a user ID and password but, later, on the basis of the security layer and the identity link. Cryptocontainer At the request of the Federal Chancellery, A-SIT has devised a universal solution for the handling of PKCS#12 certificates. The cryptocontainer 180 makes it possible to create certificates on the basis of commands and GUI so that only the variable address must be entered specially. A-SIT Infobox A-SIT 181 has made a tutorial 182 available that explains in a straightforward manner how an electronic signature is created and verified. Signature Tool The signature tool is a test tool 183 created by A-SIT with which the creation and verification of signatures for all kinds of file can be demonstrated and tested. MOA The modules for online applications were developed at the request of the Federal Chancellery and the Federal Ministry of Finance. Using MOA SP and MOA SS, electronic signatures can be verified (signature verification) and created (server signature), while persons can be identified and authenticated via MOA ID. As a basic service for conducting online procedures, the MOAs can be used free of charge by all public-administration institutions. Only the software is freely available. 184 The users themselves must take the measures necessary for, and bear the costs incurred in, its operation and any adaptation to special initial conditions. MOA ID Recurring identity Model procedures 185 for saving recurring identities have been implemented on the citizen card test sites of A-SIT Zentrum für Sichere Informationstechnologie Austria (Austrian Centre for Secure Information Technology),

134 MC EPS 2 The model code EPS 2 was developed by the Federal Chancellery. It serves as a model for authorities implementing the electronic payment system in accordance with the EPS 2 standard developed together with the banking sector. MC EPS 2 is based on the programming language JAVA. The MC EPS 2 documentation is intended to make it easier for authorities to use and adapt the electronic payment system. MC EPS 2 makes it possible to create several simultaneous connections between web clients and the bank. It should cope with an even load of 300 transactions daily. MC EPS 2 is based on the EPS 2 specification of October The web interface is based on HTML 4.01 or XHTML The use of JavaScript and Active-X is not permitted. The websites can be displayed with the web browsers Mozilla (from Version 1.3), Microsoft IE (from Version 5.0) and Netscape (from Version 6.0). An installation manual and documentation of all classes are available for programmers. Signature of Office Documents When completing online forms, 187 office documents may be signed. To do so, a citizen card is needed. After selection of the citizen card, the office document is loaded, converted and signed with the citizen card. The document can then be downloaded. Once these steps have been carried out, a confirmation site provides notification that the procedure has been completed successfully. Delivery Robot The electronic delivery protocol can, in principle, be implemented by any administrative organisation. From autumn 2004, application modules for electronic delivery (MOA-ZS) will be available to provide assistance. A very easy interface for automated electronic delivery is already available for free downloading. 188 The delivery robot delivers all documents contained in a special directory. Documents to be sent to addressees who cannot be reached electronically are filed in a print directory for subsequent printing. sspin Computation Exemplary programmes 189 in Java, PHP and Perl have been developed to demonstrate the computation of an sspin

135 E-Government Quality Mark 135

136 Much has been achieved in the field of e-government in recent years. Administrative procedures can already be conducted entirely electronically using the citizen card, electronic signatures, electronic payment and service of documents. When making use of all these technologies, the users of electronic administrative procedures place their trust in having been in compliance with the existing technical, data-protection and organisational requirements. The e-government quality mark serves as a guarantee of a high-quality implementation of e- government. Applications, procedures or products distinguished by the e-government quality mark must satisfy the defined criteria. The sign of quality reassures citizens and the private sector that they are dealing with services and products which are in line with established standards. Quality, transparency and security are fundamental principles of the Austrian system of e-government. The e-government quality mark contributes that these values are secured at long term.. The quality mark is a registered trade mark. It is awarded by the Federal Chancellery, which is responsible for e-government issues. The award procedure is administered by the ICT Strategy Unit. The detailed award criteria 190 set out the general rules, requirements to be met by bearers of the mark and provisions on the award and withdrawal of the mark: The quality mark is awarded for a period of three years. The period may be extended or the mark re-awarded. The quality mark may be awarded to software, hardware and middleware products developed in accordance with the defined criteria and standards. Bearers of the mark voluntarily undertake a commitment to fulfil the requirements imposed on the product distinguished with the mark. Notification that this commitment has been undertaken is given to the competent authority electronically by way of a registration form. 191 Mark bearers undertake an obligation to adapt their products and procedures continuously to the current technical criteria and quality standards. Applications and products must display in a clearly visible manner certain information identifying the bearer of the quality mark. Where the quality mark is used in respect of online procedures, there must be a link to that information. Quality mark bearers may be inspected at any time and they must support such supervision