Web-Services for eGovernment in Germany

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

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

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

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

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 http://www.epractice.eu/cases/dvdv

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 5.000 registries at the local level • Sometimes filed in more than one Registryin 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 EngineUniversity 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 10.000 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 SteimkeOSCI Leitstelle, Bremen, Germany