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

5
Communication levels
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

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)

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

9
Agenda

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

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

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

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

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 ltltxsdAttributesgtgt or
  ltltxsdElementsgtgt
• Documentation is derived from UML Classes
• XMeld-Specification is a docBook ltbookgt 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

14
Chain of Tools
15
Responsibilities for XMeld
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 10.000 Messages / Month

17
Agenda

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

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

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

20
Thank you very much
Frank SteimkeOSCI Leitstelle, Bremen, Germany