Download ppt - EGov Interop'05 - Feb 23-24, 2005 - Geneva (Switzerland) OBSERVATORY ON INTEROPERABLE eGOVERNMENT SERVICES eGov-Interop'05 Annual Conference 23 -24 February

eGov Interop'05 - Feb 23-24, 2005 - Geneva (Switzerland)

OBSERVATORY ON INTEROPERABLE eGOVERNMENT SERVICESeGov-Interop'05 Annual Conference23 -24 February 2005 – Geneva (Switzerland)

Hungarian Electronic Public Administration Interoperability Framework (MEKIK) –

Technical Standards Catalogue

Csaba Krasznay

Budapest University of Technology and Economics Centre of Information Technology

Hungary

Csaba Krasznay eGov Interop'05 - Feb 23-24, 2005 - Geneva (Switzerland)

2

Contents

• Preliminary research• Initial statements• Realization of methodology• Security framework


3

Background

• EU expectations for „one-window administration”• Hungarian Ministry of Informatics and

Communications realized the lack of interoperability

• The project „Hungarian Electronic Public Administration Interoperability Framework (MEKIK)” began


4

Aims

• The scope of project was:– Declaration of the necessary standards– Definition of work-flows

• Experts should bear in mind the EU funded Interchange of Data between Administrations (IDA) project, focusing on:– Accessibility– Multilingualism– Security– Protection of private data– Subsidiarity– Usage of open standards– Usage of open source code application


5

Initial statements

• During the preparatory work, the project team examined the solutions, standards and best practices of the United Kingdom, Sweden, Germany, France, Denmark, Australia and the EU

• This work resulted some technical suggestions:– The interoperability framework shall be based on XML

(SOAP protocol, XML Signature, XML Encryption, XSD Schemas)

– Security features are based on Public Key Infrastructure

– Future technologies, such as WSDL and UDDI are mentioned

– A portal for standard catalogue and middleware is a must


6

Sources of the catalogue

• Second step for developing the standard catalogue is to sort the technical standards

• Experts took into consideration the German and British examples, SAGA and e-GIF

• Two main categories were made:– Data structures, message structure standards, that can be

different in each countries,– All other (mainly open and accessible) international technical

standards

• Developers of systems for public administration shall design their product by using these standards


7

Metadata

• Experts should make a choice about the form of the standard catalogue:– One document with the whole standard catalogue (British

model)?– Browsable and searchable portal (Danish model)?

• The final decision was to make both of them• Documents in the portal shall be classified with

metadata• Best metadata structure for that purpose is

Management Information Resources for eGovernment (MIReG) which based on Dublin Core


8

Middleware

• The middleware must be able to communicate and process messages based on the standards listed in the catalogue

• It has the following functions:– Identification

– Authentication

– Authorization

– Managing message transfer

– Making entries in the logfile

– Converting data

– Managing security services


9

Security in public administration

• Security is emphatic part of the interoperability project which was controlled by the Ministry of Informatics and Communications, the Prime Minister’s Office and the Ministry of Interior

• Main topics were:– Security framework– CA requirements– Application requirements– System requirements– Access control management– Smart card specification– Mobile phone authentication


10

Security framework

• Defines the levels and categories of security aspects in A2A, A2B and A2C communication

• Experts established 5 functional and 1 assurance requirements:– Registration

– Authentication

– Integrity

– Confidentiality

– Non-repudiation

– Conformance


11

Electronic signatures in public administration

• 3 + 1 electronic signature security levels were also laid down:– level 0: no expectation (there is no need to use electronic

signature),

– level 1: low expectations (advanced electronic signature is needed with software token),

– level 2: average expectations (advanced electronic signature is needed with hardware token),

– level 3: high expectations (qualified electronic signature is needed with secure signature-creation device).


12

Certificate Authority requirements

• CA’s have distinguished role in the security framework• 6 types of different CAs are necessary to serve electronic

public administration:– issuing secure signature-creation device with qualified certificate,

– issuing secure signature-creation device with authentication certificate for citizens,

– secure signature-creation device with authentication and encryption certificate for civil servants,

– issuing hardware token with signature and encryption certificate,

– issuing software token with signature and encryption certificate,

– time-stamping service provider.

• Key recovery rules were also created for public servant’s encrypting keys


13

Smart card specification

• Hungarian eID card is called HUNEID• It is a public key enabled smart card• Based on CEN CWA 14890• Environment of these cards is also defined• This is the basis of all A2B and A2C services• Sample application exists


14

Legal aspects

• This technical framework can be successful if it is demanded for all e-governmental development

• Legislation work is needed to establish the legal environment for the framework

• Experiences of the United Kingdom and Austria were assimilated

• Still under development• The Hungarian Government will accept the legal

background of the framework in April


15

PPP

• Real interoperability is just a dream without the private sector

• The Hungarian Electronic Signature Association has a standardization work to comply the framework’s specifications

• All Hungarian certificate authorities and software developers participate in this work

• We hope that we can make real interoperability with this work in the field of certificate profiles and XML signatures


16

SWOT

• Strengths– Complex framework based on international experiences

– All parts were created by the best experts in Hungary

• Weaknesses– Most fields are not yet widely used, the technical implementations are

missing

– It’s still not complete

• Opportunities– Interoperability between governmental services

– Guide for private implementations

• Threats– Lack of funds

– Low level of awareness


17

References

• [1] Hungarian documents of MEKIK project are accessible at the following URL:

http://www.itktb.hu/engine.aspx?page=elka_oldal

• [2] Common list of basic public serviceshttp://europa.eu.int/information_society/eeurope/2002/action_plan/pdf/basicpublicservices.pdf


18

Questions?

Thank you for your attention!