E-GOV Web-Services for eGovernment in Germany Brussels, Feb. 19, 2009 OASIS eGov Member Section Frank Steimke OSCI 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 4 OSCI Transport Version 1.2  Open Standard, developed in 2001 … 2002  Experts from Government and Industry  Based on W3C Standards XML digital signature and XML encryption  No WS* - Stack at this time  Profiled to meet German and European Laws (digital signature act)  Double-Envelope (Container) schema  Application independent  Sharing resources without loss of confidentiality  Uses Internet (http)  Allows economic Implementation at the local Government Level  Successfully checked against ITSEC

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

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 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) OSCI XMeld  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 > or >  Documentation is derived from UML Classes  XMeld-Specification is a docBook 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 14 Chain of Tools

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

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 Steimke OSCI Leitstelle, Bremen, Germany