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)
- authorization and representation (MOA VV)
- official signatures (MOA AS)
- 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 (smart card or mobile phone signature),
- communicating with the browser and citizen card environment,
- authenticating and identifying citizens, businesses and authorities using the digital signature and identity link,
- connecting to the Supplementary Register for Natural Persons to support foreign
- 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.
To have a common look and feel, a "template" for selecting the citizen card login is provided. Recognition of common logos, buttons, and appearance shall ease using the citizen card in teh various applications.
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 authentication 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.
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-VV
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 the 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.
MOCCA
MOCCA an Open Source citizen card software. Implemented in Java, a solution independent from the operating system has been achieved. Two deployment models are supported: MOCCA can either be installed at the citizen PC or can be provided by service providers as an applet. The latter, referred to as Online-BKU, implements a minimum footprint approach so that no specific installation at the client is needed.
MOCCA implements the essential functions of the citizen card specification "Security Layer". These functions are:
- communication with the cards reader and the smartcard via PC/SC,
- reading the identity link and calculation of private sector-specific identifiers,
- processing and creating qualified electronic signatures following XMLDSIG,
- implementation of the security management functions to limit communication to trustworthy SSL-secured sites, and
- support functions such as PIN handling.
- n addition to Austrian smartcards (health-insurance cards, bank cards, service cards, etc.), foreign eDI and signature cards are supported. To date this includes smart cards and eDi from Belgium, Estonia, Finland, Iceland, Italy, Liechtenstein, Lithuania, Portugal, Spain, and Switzerland.
PDF-AS
This module supports qualified electronic signatures on PDF documents using the citizen card. Both smartcards and the mobile phone signature are supported. The electronic signature is embedded into the PDF as a visual signature block. This supports so-called official signatures which is the means for public authorities to issue authentic electronic documents. The module may however as well be used in private sector or daily life processes such as signing contracts or electronic invoices.
Two signature formats are supported: The binary mode covers the whole PDF document including text, graphics, or forms. The text mode extracts the raw text data. For simple document structures this allows for reconstructing and verifying electronic signatures from printouts.
PDF-AS has been implemented in Java. It supports creation of electronic signatures and embedding these into the PDF via an interface. This interface can be used by other applications, such as client tools to sign PDF at the citizen’s PC, as well as server applications to sign official notifications or electronic invoices in a process engine.
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 ZS 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.