Transcript Open Standards in eGovernment

E-GOV
Web-Services
for eGovernment in Germany
Brussels, Feb. 19, 2009
OASIS eGov Member Section
Frank Steimke
OSCI Leitstelle, Bremen, Germany
At a glance
E-GOV
 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
Folie 2
Agenda
E-GOV
 Web Services Security: 1st Approach, OSCI-Transport 1.2
 Standardization at the Application Level
 Next Steps
Folie 3
Communication levels
E-GOV
Standardized message exchange (Application level)
Internet / http
Folie 5
Reliable One-Way Scenario
E-GOV
 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
Folie 6
Implementation of OSCI-Transport 1.2
E-GOV
 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)
Folie 7
German Government Services Registry (DVDV)
E-GOV
 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
Folie 8
Agenda
E-GOV
 Web Services Security: 1st Approach, OSCI-Transport 1.2
 Standardization at the Application Level
 Next Steps
Folie 9
Civil registration in Germany
E-GOV
 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
Folie 10
Amendment of Federal Law
E-GOV
 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
Folie 11
Application Level Standardization
E-GOV
 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
Folie 12
Single source modeling
E-GOV
 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
Folie 13
Responsibilities for XMeld
E-GOV
Folie 15
New services for TAX purposes
E-GOV
 New centralized Database for TAX purposes
 Unique TAX-ID for every citizen
 Services offered by TAX Registry




Insert
Forced-insert
Update
Delete
Local
Registry
Local
Registry
 Services offered by Residents Registry
 Accept-tax-ID
 Check-for-duplicates
 Services are described in OSCI-XMeld
Centralized
Registry for
TAX purposes
Local
Registry
 Security assured by OSCI-Transport
 In use since 2008
 More than 10.000 Messages / Month
Local
Registry
Folie 16
Agenda
E-GOV
 Web Services Security: 1st Approach, OSCI-Transport 1.2
 Standardization at the Application Level
 Next Steps
Folie 17
OSCI Transport 2 and SAFE
E-GOV
 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
Folie 18
Application interoperability Issues
E-GOV
 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) ?
Folie 19
E-GOV
Thank you very much
Frank Steimke
OSCI Leitstelle, Bremen, Germany
Folie 20