E-GOV

Web-Services for eGovernment in Germany

Brussels, Feb. 19, 2009

OASIS eGov Member Section

Frank SteimkeOSCI Leitstelle, Bremen, Germany

E-GOV

Folie 2

At a glance

Security as a key requirement for eGovernment Web Services Paperless processes Electronic Forms with electronic Signatures Encryption for confidentiality, PKI for authentification

Development of OSCI-Transport 1.2 in 2002 Secure message exchange based on XML-Technologies Implementing a Registry for OSCI-Transport bases Web-Services

Interconnecting the Registries of Residents as Killer-application Standardization at the application level (OSCI-XMeld) Nation-wide in use since Jan. 1, 2007 Other applications followed (e. g. Interior, Justice, Finance)

Next steps Adopting international “web service security” in OSCI-Transport 2 New Projects at the European level

E-GOV

Folie 3

Agenda

Web Services Security: 1st Approach, OSCI-Transport 1.2

Standardization at the Application Level

Next Steps

E-GOV

Folie 5

Communication levels

Internet / http

Standardized message exchange (Application level)

E-GOV

Folie 6

Reliable One-Way Scenario

User 2 acts as a service provider

Intermediary acts as mandatory controller unable to decrypt message content

Delivery is recorded, can be retraced and confirmed

Service result can be sent back in a independent transmission Processing of the message is done behind the scenes

E-GOV

Folie 7

Implementation of OSCI-Transport 1.2

Described in terms of XML-Schema Data structures for atomic messages (e. g. forward delivery request) Problem with schema definition (Early version of XML-DSIG & XML-ENC)

Client components available free of charge and open source OSCI-Transport library Supplied by the government to support the use of OSCI-Transport Available in JAVA and .NET

Server components available as commercial products Developed and maintained by Industry

Different types of integration OSCI-Transport library integrated in desktop applications Intermediary integrated into legacy middleware Special purpose middleware products (usually file-system based)

E-GOV

Folie 8

German Government Services Registry (DVDV)

Build from scratch as a distributed system Organizations and services managed in an LDAP tree Master is operated by federal government Slaves with replicated data at the federal state level

Maps service requests to data of communication endpoints Request: service (‘xmeld-0201’, ‘bremen’) Response: endpoint (X509-certificates, URI-of-intermediary, …) Acts as a Indicator for non-mandatory services

“Is service xmeld-0410 offered by the registration office in Bremen ?”

Describes in terms of WSDL, but … Usually the service descriptions are hardcoded in the legacy systems Transport-Binding is proprietary up to now (OSCI-Transport 1.2)

EU eGovernment Award 2007 for effective and efficient administration See http://www.epractice.eu/cases/dvdv

E-GOV

Folie 9

Agenda

Web Services Security: 1st Approach, OSCI-Transport 1.2

Standardization at the Application Level

Next Steps

E-GOV

Folie 10

Civil registration in Germany

Mandatory for all residents

Used as a Source of Information about Citizens for many purposes Municipal Administration and Statistics Private Parties (Find someone's Address) Security purposes

Decentralized System with more than 5.000 registries at the local level Sometimes filed in more than one Registry

in case of Residences in different Municipalities Need of Message exchange to keep Registries synchronous More than 20 legacy Systems to operate these Registries

E-GOV

Folie 11

Amendment of Federal Law

Prerequisites: Law and Techniques for Secure Data Exchange German Digital signature Act (2001) OSCI – Transport (2002) Public Key Infrastructure with Certificates for Registration Offices ( Centralized Registry for electronic Services )

Commitment of Ministries of Interior for Automation Based on open Standards for Transport and Application Level Protection of Investment for Legacy Systems

Amendment of Federal Law took place in 2002 Transitional period ends in 2006

Electronic Data Exchange became … Mandatory for messages between registries in different federal states

Every Vendor was obliged to implement the standards Mandatory for Federal Authorities Possible for Inquiries and other messages

E-GOV

Folie 12

Application Level Standardization

OSCI XMeld (XML für das Meldewesen)

Open Standard, designed for civil registration in Germany Based on the German federal law about Content of Registries E. g. Name, Address, Locations, Citizenship, Tax data … Described in Terms of UML Classes Implemented as Types in XML Schema, derived from UML

Messages for Processes in Civil Registration Based on Data exchange liabilities in the Federal Law E. g. Inquiries, Synchronization between Registries, … Described in Terms of UML Classes:

Aggregations of Base Data Structures Implemented as Root-Elements in XML Schema, derived from UML

OSCI XMeld-Message XML Document Instance, valid with Respect to OSCI-XMeld Schema Signed, encrypted and transferred within OSCI-Transport Infrastructure

E-GOV

Folie 13

Single source modeling

Modeling is done within UML Use Cases, Activity Diagrams, Class Diagrams Single source for Schema and Documentation guarantees Consistency

XML-Schema is derived from UML Classes Using the UML profiling Mechanism (“UML-Profil für XÖV”) Generation of <<xsdAttributes>> or <<xsdElements>>

Documentation is derived from UML Classes XMeld-Specification is a docBook <book> which consists of Fragments, automatically generated from UML Classes Manually written parts

Software “XGenerator” has been written for this Task Open Source Java Project, hosted at Sourceforge Eclipse Modeling Framework (EMF) USE, an A UML based Specification Environment with OCL Engine

University of Bremen, Germany

E-GOV

Folie 15

Responsibilities for XMeld

E-GOV

Folie 16

New services for TAX purposes

New centralized Database for TAX purposes

Unique TAX-ID for every citizen

Services offered by TAX Registry Insert Forced-insert Update Delete

Services offered by Residents Registry Accept-tax-ID Check-for-duplicates

Services are described in OSCI-XMeld

Security assured by OSCI-Transport

In use since 2008 More than 10.000 Messages / Month

LocalRegistry

LocalRegistry

LocalRegistry

LocalRegistry

CentralizedRegistry for

TAX purposes

E-GOV

Folie 17

Agenda

Web Services Security: 1st Approach, OSCI-Transport 1.2

Standardization at the Application Level

Next Steps

E-GOV

Folie 18

OSCI Transport 2 and SAFE

OSCI-Transport 2: secure web services profiled for German needs Bases on international standards from WS* and WS-Security Profiling is done to meet German (and European) laws Some extensions for issues known from Version 1 Experiences Specification will be published soon Implementation will be done by using WS-Frameworks (Apache, SUN, MS)

SAFE: Secure Access for Federated eGovernment Standardized interfaces to identity management techniques Registration, authentication, authorization of communication participants Based on WS*-Stack, profiled to improve interoperability Basic part: Application independent Further profiling for applications in eJustic in a second part Shall be used in conjunction with service Registry and OSCI-Transport 2

E-GOV

Folie 19

Application interoperability Issues

Status quo Different Standards at the application level

Problem: Interoperability Issues with legacy systems and –data Every system has its own information model … … which is usually not explicit Sometimes they are not easy to transform Sometimes they are conflicting

How to develop a common nucleus for eGov-Message exchange ? What about OASIS Core Componentes, part of ebXML? How to deal with legacy data?

Common data structures or transformation and conversion Top down or bottom up? Costs (Invest and long term) ?

E-GOV

Folie 20

Thank you very much

Frank SteimkeOSCI Leitstelle, Bremen, Germany