Modules for Online Applications
Modules for online applications (MOA) are software components that encapsulate all the procedures needed to carry out specific functions, as mandated by the eGovernment strategy. They also implement interfaces for web applications. These modules make the intended functionality easier to integrate into applications. Some of the implemented functions include: verifying and affixing electronic signatures, reading identification data from the citizen card, and delivering notifications from authorities.
Right from the beginning, modules for online applications were conceptualised by the eGovernment Strategy for implementing interfaces on the basis of international open standards and for making licenses available for free. The fundamental specifications were published openly and since June 2005 the modules have been offered as open source software. This means that the source code can be looked at and further developed by anyone.
In the meantime, many eGovernment applications use these modules as indispensable components of their system. For this reason, the software is continually maintained in a collaborative process and upgraded to fulfil new requirements. For this purpose, a was created for the developer community so that feature and change requests, error reports and enhancements could be collaborated on in a structured way. The modules and all their versions including the source code are available on the platform. Currently, modules exist which support the following functionalities:
- identification (MOA ID)
- signature verification (MOA SP)
- server-side signature creation (MOA SS)
- delivery (MOA ZS)
MOA ID
This module is used to uniquely identify and authenticate users securely who want to conduct online procedures with their citizen cards. The server-side MOA and the client-side citizen card software interact with each other to carry out identification and authentication using the identity link and the signature on the citizen card.
This logon process ensures the highest level of security for accessing records and accounts, carrying out bank transactions, and for all branches in which personal information and data is stored. The MOA ID links a session to specific user data from the identity link, such as the sector-specific personal identifier, which the MOA ID calculates from the sourcePIN on the citizen card. The MOA ID includes functionality for accessing the citizen card environment, communicating with the browser and citizen card environment, authenticating and identifying citizens, businesses and authorities using the digital signature and identity link, calculating the ssPIN and forwarding the user’s login information to the subsequent application. The layout of the web pages that are used in these processes can be changed to match the organisation’s corporate design.
After authentication is successfully carried out, the application requests the login data from the MOA ID over a web service or a Java interface. Alternately, a proxy component can be used to transmit the login data over other protocols (for example in a HTTP header parameter) for web applications that do not support web services or internal Java calls. This makes integrating authentification processes into existing online applications easy and uncomplicated.
However, new eGovernment applications should be designed so that proxy components are no longer necessary. Through the use of sector-specific personal identifiers in business applications, the eGovernment Act allows the citizen card to be used for identification purposes in the private sector.
Public authority procedures can also be carried out online by third-parties on someone else’s behalf, as long as a valid electronic proxy authority agreement exists between the parties. The MOA VV (authorization and representation) was originally created for this purpose. It was able to authenticate electronic proxy agreements and recognize proxy limitations. The functionality of the MOA VV was also integrated into the latest version of MOA ID.
For professional representatives (lawyers, civil engineers or administrative officials, who have authority to act in accordance with §5(3) eGovernment Act), the certificate extension of the signature certificate in the citizen card shows that the representative is authorised to conduct electronic transactions on behalf of the principal. After the representative logs in with the citizen card, the MOA ID is able to forward his identification data along with data of the principal to the application. In contrast to electronic proxy representation, where the data of the representative can be viewed in the XML structure of the proxy agreement, the principal is identified by entering attributes such as name, date of birth and place of birth on the login pages. The principal is identified over a web service from the sourcePIN Authority, which sends his registration data back to the MOA ID. The MOA ID then sends the data to the subsequent application.
MOA SP/SS
This module encapsulates all functionality needed for server-side signature creation and verification. Signatures can be created using software certificates or with a hardware security module. The MOA module supports signatures and qualified signatures. In order to create and verify signatures in the citizen card environment, the process and the XML-based query and response messages must conform to the citizen card specification.
During the creation of a signature, the module must look after obtaining the signature key, resolving of the data to be signed, calculating the transformation and creating the signature itself. It is also possible to create batch signatures with just one command that can be attached to many documents.
Just like in the MOA ID, its functions can be called by SOAP web services as well as by Java program interfaces. The web service interface makes it possible to maintain a clean separation between the calling applications and MOA components. In addition to providing the option for multitenancy, this design allows centralised modules to be shared by many applications.
MOA ZS
The MOA ZS module creates the interface that is used between record delivery services and electronic file systems or special applications. It carries out a series of individual steps on its own, hidden from the user, that is necessary for the electronic transmission of tasks in a lawful and verifiable way.
With dual delivery, MOA is responsible for communicating with the delivery agent, evaluating the method of delivery, encrypting the content of the electronic document (if required) and sending documents to a printing facility or an electronic delivery service. The confirmation of receipt from the delivery service to the authority is also sent back through the module's web services.
The module saves application developers time and effort by implementing important basic steps in the electronic delivery procedure and thereby contributes to a rapid and cost-effective proliferation of electronic delivery. A trial implementation of it is already being carried out in the ELAKof the federal administration.
MOA AS
In order for authorities to make use of the popular PDF (Portable Document Format) for electronic communication with citizens, an Official Signature must be able to be affixed to the PDF documents as specified in the eGovernment Act. According to §19 of the eGovernment Act, the document must be affixed with the Official Signature and the logo of the authority. MOA AS offers a simple web service for attaching such signatures to PDF documents, which can still be reconstructed and validated even after being printed on paper.
MOA AS extends the functions of the signature module MOA SS/SP for attaching and validating PDF signatures. MOA SS/SP was specially developed for the signing of XML documents and therefore is not suitable for use as an Official Signature on its own. On the other hand, MOA AS makes it possible for eGovernment applications to add administrative signatures to common document types such as PDF, Microsoft Word or Open Document Format (ODF) so that they can be used for communication with citizens.
The specified PDF signature can be used for more than just communication by public administrations. It can also be put to use in the private sector as a simple way to sign orders and invoices electronically.