Web-Services for eGovernment in Germany by kwd15566



          for eGovernment in Germany

                  Brussels, Feb. 19, 2009
                  OASIS eGov Member Section

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

                                                                         Folie 2

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

                                                            Folie 3
           Communication levels

Standardized message exchange (Application level)

                  Internet / http
                                                    Folie 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
                                                                  Folie 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)

                                                                            Folie 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

                                                                              Folie 8

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

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

 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

 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

 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

                             Folie 15
                       New services for TAX purposes

 New centralized Database for TAX purposes
 Unique TAX-ID for every citizen
 Services offered by TAX Registry          Local
      Insert                              Registry

      Forced-insert
      Update
      Delete                               Local

 Services offered by Residents Registry
    Accept-tax-ID                                      Centralized
                                                        Registry for
    Check-for-duplicates                              TAX purposes
 Services are described in OSCI-XMeld
 Security assured by OSCI-Transport
 In use since 2008                         Local
    More than 10.000 Messages / Month

                                                             Folie 16

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

                                                            Folie 17
                         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

                                                                                   Folie 18
                    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) ?

                                                                   Folie 19

Thank you very much

Frank Steimke
OSCI Leitstelle, Bremen, Germany

                                   Folie 20

To top