1. Web-Services for eGovernment in Germany
Brussels, Feb. 19, 2009
OASIS eGov Member Section
Frank Steimke OSCI Leitstelle, Bremen, Germany

2. Security as a key requirement for eGovernment Web Services
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

3. Agenda
Web Services Security: 1st Approach, OSCI-Transport 1.2
Standardization at the Application Level
Next Steps

4. Standardized message exchange (Application level)
Communication levels
Standardized message exchange (Application level)
Internet / http

5. 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

6. 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)

7. 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

8. Agenda
Web Services Security: 1st Approach, OSCI-Transport 1.2
Standardization at the Application Level
Next Steps

9. 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 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

10. 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

11. 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

12. 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

13. Responsibilities for XMeld

14. 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 Messages / Month

15. Agenda
Web Services Security: 1st Approach, OSCI-Transport 1.2
Standardization at the Application Level
Next Steps

16. 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

17. 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) ?

18. Thank you very much
Frank Steimke OSCI Leitstelle, Bremen, Germany