Main content

Modules for Online Applications

Software components that make the implementation of procedures needed to carry out specific functions mandated by the eGovernment strategy 

Online Application Modules

Online Application Modules (MOA) are software components that make the implementation of procedures needed to carry out specific functions mandated by the eGovernment strategy easier by encapsulating the necessary procedures together. They also provide interfaces for Web applications. Some of the implemented functions include: verifying and affixing electronic signatures, reading identification data from the citizen card, and delivering official documents from authorities.

Right from the beginning, MOAs were conceptualised for implementing interfaces on the basis of international open standards and for providing free licenses. The fundamental specifications were published openly and the modules have been offered as open source software since June 2005. Open source means that the source code can be looked at and further developed by anyone.

In the meantime, many eGovernment applications make use of MOA components and its modules have become indispensable components of the system. For this reason, the software is continually maintained in a regulated collaborative process and upgraded to fulfil new requirements. For this purpose, the joinup platform of the European Commission issued on which feature and change requests, error report and enhancements can be collaborated on by the developer community 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 functionality:

  • identification (MOA ID)
  • signature verification (MOA SP)
  • server-side signature creation (MOA SS)
  • delivery (MOA ZS)
Overview of the online-application modules: Identification (MOA ID), Signature verification (MOA SP), Server-side signature creation (MOA SS), Delivery (MOA ZS)


This login process provides 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 login 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 selecting the citizen card environment, communicating with the browser and citizen card environment, authenticating and identifying citizens, businesses and representatives of the authorities using the digital signature and identity link, computing the ssPIN and forwarding the user’s login information to the subsequent application. The Web pages that appear in these procedures can be configured 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. Alternatively, a proxy component can be used to transmit the login data over other protocols (e.g., in a HTTP header parameter) for Web applications that do not support Web services or internal Java calls. Proxy components make integrating authentication processes using the citizen card into existing online applications easy and uncomplicated. However, newly developed eGovernment applications should be designed so that proxy components are not necessary.

The specification of sector-specific personal identifiers for the private sector in the eGovernment Act allows the citizen card to be used for identification purposes in business applications in the private sector. The upgraded features developed in the MOA WID project for the creation and use of sector-specific personal identifiers have been integrated into the newest version of the MOA ID by organisations in the private sector.

Procedures from online authorities can also be carried out by third-parties on someone else’s behalf, as long as a valid electronic mandate agreement exists between the parties.  For this purpose, MOA ID has a connection to the online mandate service of the SourcePIN register authority in which users can select a mandate. The selected mandate is then signed electronically and handed over to the subsequent application via MOA ID.For professional representatives (e.g., lawyers, civil engineers or administrative officials as per §5(3) E-GovG), the standardised extension of the signature certificate in the citizen card shows that the representative is authorised to conduct electronic procedures on behalf of the principal. After the representative logs in with the citizen card, the MOA ID is able, via the online mandate service, to forward his or her identification data along with the data of the principal to the application. In contrast to electronic mandates, where the data of the representative can be viewed in the XML structure of the mandate, the principal is identified by entering attributes such as name, date of birth and place of birth on the pages of the online mandate of the SourcePIN register authority. The principal is identified over a Web service from the SourcePIN Authority, which sends his or her registration data (e.g., the ssPIN) back to the MOA ID. The MOA ID then sends the data in the form of an electronic mandate to the subsequent application.


This module encapsulates all functionality needed for server-side signature creation and verification. Signatures can be created using software certification or with a hardware security module. This module supports signatures according to XMLDSig and CMS for both simple 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 transmit the signature key, resolve the data to be signed, compute the transformations and create the signature by itself. It is also possible to create batch signatures with just one command that can be affixed to many documents.

Just like in the MOA ID, the 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 multiple client capability, this design allows centralised modules to be shared by many applications.


The MOA ZS module implements the interface that is used between record management services or special applications and delivery services. It carries out a series of individual steps on its own, hidden from the user, that are necessary for the transmission of documents in a legal and verifiable (electronic) way.

With dual delivery, MOA ZA is responsible for communicating with the central lookup service, evaluating the method of delivery (electronic, conventional), affixing the official signature, encrypting the content of the electronic document and sending documents to a printing facility or an electronic delivery service. The proof of delivery receipt from the delivery service to the authority can also be sent back through the MOA ZA Web services.

This module saves application developers time and effort by implementing the main steps in the electronic delivery procedure and thereby contributes to a rapid and cost-effective proliferation of electronic delivery. An implementation of it has already been carried out in the Federal Government in ELAK.

MOA AS and PDF Over

In order for authorities to make use of the popular PDF document format for electronic communication with citizens, an official signature must be able to be affixed to PDF documents as specified in the eGovernment Act. According to §19 of the E-GovG, the document must be affixed with the official signature and the logo of the authority. MOA AS provides a simple Web service for affixing such signatures to PDF documents.

MOA AS extends the functions of the signature module MOA SS/SP for affixing and verifying PDF signatures. MOA SS/SP was specially developed for signing XML documents and therefore is not suitable for use as an official signature on its own. MOA AS should make it possible for eGovernment applications to affix official signatures to common document types such as PDFs 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.

The equivalent to the MOA AS in PC environments is the PDF-Over, which is a tool with which a PDF document can be signed in qualified form using the citizen card as a chip card or mobile phone signature.


The module MASS allows official signatures to be affixed in special applications in batch mode. During this process, documents are extracted from print stream data, the official signature is affixed automatically e.g. in PDF-AS format, and the signed documents are inserted back into the print stream.

Further information