The Modules for Online Applications (MOA) are components that support the implementation of the Austrian eGovernment strategy. The modules in this project provide functions for the creation and verification of electronic signatures (MOA-SPSS) as well as for the identification and authentication of citizens in electronic procedures.

MOA-ID function

Figure 1 shows the typical flow of an MOA-ID-based authentication to an online application. The following components are basically involved in the authentication process:
  • Online application: This is a server-side Web application that requires secure authentication of users for access to specific resources (Web pages, etc.).
  • Browser: A Web browser is used to access the Web application.
  • MOA-ID: This component implements the authentication process and provides the respective authentication data to the online application after successful authentication based on which the online application can uniquely identify the user.
  • Citizen Card Environment: The Citizen Card environment (CCE) implements the Security Layer interface and with it, provides access to the Citizen Card of the user.

 flow of an MOA-ID-based authentication to an online application

Figure 1: Typical flow of an MOA-ID-based authentication to an online application.

An authentication to the online application via MOA-ID is basically divided into the following steps:
  1. The user requests access to a resource of the online application via the browser.
  2. The online application verifies whether access to the requested resource is only provided for authenticated users.
  3. If authentication is required, then the user is forwarded to a respective authentication page of the online application.
  4. The authentication component MOA-ID is called via a suitable HTTP-POST request.

  5. MOA-ID sends an InfoBoxReadRequest in the reply to this request in accordance with the security layer specification to read the identity link on the browser.
  6. This request is then sent from the browser to the Citizen Card environment.
  7. The Citizen Card environment processes the received request and reads the identity link from the Citizen Card of the user.
  8. The identity link is transferred to MOA-ID via the DataURL (see security layer specification).

  9. The signature of the identity link is verified by MOA-ID.
  10. As a reply to the identity link, MOA-ID sends a signature request via the open DataURL connection as a reply to the Citizen Card Environment.
  11. The Citizen Card Environment processes the request and initiates the signature creation through the Citizen Card of the user.
  12. The created signature is transfer to MOA-ID via the DataURL.

  13. MOA-ID verifies the received signature and creates an SAML assertion, which contains relevant authentication data.
  14. Via the Citizen Card Environment, the user is passed back (redirect) to the online application. The redirect contains a unique SAML artefact through which the SAML assertion can be picked up by MOA-ID within a certain amount of time.
  15. The online application extracts the SAML artefact and with it, picks up the SAML assertion from MOA-ID.
  16. On the basis of the authorization information in the SAML assertion, the application grants or refuses the user access to the protected resource.

Although the entire authentication process seems to be somewhat complex, the integration of MOA-ID into a Web application is relatively easy. The majority of the functionality (communication with the Citizen Card Environment, etc.) is implemented exclusively by MOA-ID and does not have to be taken into consideration in any more depth for integration into a Web application.

MOA-ID integration

Selection of the Citizen Card Environment

As the first step in the scope of an MOA-ID-based authentication of users, the online application must offer a selection page that the users can use to select the Citizen Card Environment that they prefer. There are currently the "chip card" and "mobile phone signature" available as alternatives for this. When using chip cards, users can also choose between using a locally installed Citizen Card Environment or a Java applet based approach.

MOA-ID supports application operators with the integration of a suitable selection page. For example, MOA-ID contains a template in the form of an HTML file that can be integrated as a selection page in online applications. Figure 1 shows the template provided by MOA-ID. It can be modified easily in accordance with the requirements and layout of the online application. The documentation for adapting this template can be found in the respective release.

Figure 1: Template provided by MOA-ID for the integration of a selection page for preferred Citizen Card configurations

If the complete template shown in Figure 1 cannot, or is very difficult to integrate into an existing layout, then only part of the template can be used optionally. For example, the area called "Login with Citizen Card" at the top – i.e. the actual Citizen Card selection – could be integrated in an existing application via an HTML IFRAME. 

Naturally the entire functionality of the offered template can also be implemented by the application operator himself in order to ensure optimum and smooth integration in existing applications. In this case, the template offered by MOA-ID can at least be used as a draft.

Invocation of the MOA-ID authentication component

Independent of the Citizen Card configuration selected by the user, a respective request must be sent to MOA-ID to start the MOA-ID based authentication. This must be in the form of an HTTP POST request. Listing 1 shows an example of a call of MOA-ID under the assumption that the mobile phone signature was selected as a Citizen Card.

As the "action" attribute of the HTML FORM tag, the URL under which the MOA-ID is reachable must be given. Here, MOA-ID can be operated on the same or also on an external server. The important thing is that the "StartAuthentication" servlet is given explicitly by MOA-ID as the URL to be called. In addition, the URL parameter "OA" must be added to the given URL. This defines that URL to which MOA-ID transfers the SAML artefact to pick up the SAML assertion after successful authentication. Therefore, in the example shown in listing 1, the online application provides a servlet under /moaid-servlet that can be called by MOA-ID and can accept the SAML artefact (see also the following section regarding this).

Listing 1: Call from MOA-ID via HTTP-POST.

Furthermore, the two input parameters "Template" and "bkuURI" can be given. Via the parameter "Template", a URL is defined under which MOA-ID can pick up a template from the online application that is required for the login. Via this template, various parameters can optionally be specified for the integration of the mobile phone signature (or alternatively the respective selected CCE).
Templates that can be used for the individual Citizen Card implementations are also provided by MOA-ID and can easily be taken over in the online application. The template provided by MOA-ID for using the mobile phone signature is shown in listing 2. Similarly prepared templates also exist for using chip card based Citizen Card configurations.

Listing 2: Template for using the mobile phone signature.

Besides the parameter "Template", the input parameter "bkuURI" can also be given when calling MOA-ID. This defines the URL to the Citizen Card Environment (mobile phone signature, etc.) selected by the user. The example shown in listing 1 links this parameter to the mobile phone signature instance operated by A-Trust.

After sending the Web form shown in listing 1 to MOA-ID, the authentication process is started and executed automatically. The online application not directly involved in the authentication of the user. It only has (for example via an HTML IFRAME tag) to integrate the GUI component of the selected Citizen Card Environment. When using the template provided by MOA-ID, this is taken over by this template.

Retrieve the SAML assertion

After authentication by MOA-ID with the use of the Citizen Card, MOA-ID is in possession of the necessary authentication data. They are structured accordingly in an SAML assertion. To finally conclude the authentication process, this SAML assertion must be transferred to the online application. To do this, the user is forwarded to the online application with an SAML artefact parameter. The SAML artefact can be uniquely assigned to an SAML assertion. The online application can use this SAML artefact to retrieve the SAML assertion in MOA-ID.
To transfer the SAML artefact, MOA-ID forwards the user to the online application, which was defined through the URL parameter "OA" as shown in listing 1. Behind this URL, there is usually a servlet of the online application, which later reads the SAML artefact. Listing 3 shows how the SAML artefact can be read from the request sent by MOA-ID via the "SAMLArtifact" identifier based on a concrete example.

Listing 3: Reading the SAML artefact.

With the help of the SAML artefact received this way, the SAML assertion can be picked up later by MOA-ID. MOA-ID provides a respective Web service interface for this. This interface is reachable under the following URL:

The online application must therefore implement a respective client that transfers the SAML artefact to the Web service interface provided by MOA-ID in order to pick up the related SAML assertion. The setup of the respective request as well as the received response follows the SAML 1.0 standard.

Listing 4 illustrates an SAML request to pick up an SAML assertion that is referenced via the SAML artefact "AAH5hs8aaZSFYHya0/cmtJ3QAR7rf54uhIsEcDMZFmmZ1/Qldrdf4JSK". The SAML request is already embedded in a SOAP request, which can be sent to MOA-ID later.

Listing 4: Example of an SAML request for picking up the SAML assertion by MOA-ID.

The client to be implemented by the online application must therefore generate a specification-conforming SAML request from the received SAML artefact, embed it into a SOAP request, and then send it to the Web service interface of MOA-ID.

Extraction of the authentication datan 

If MOA-ID can find a related SAML assertion for the transferred SAML artefact, then it is transferred to the online application in the reply to the transferred Web service request. Like the SAML request, the received SAML response is orientated around the SAML 1.0 standard.

Listing 5 shows an example of an SAML response. The element "", which contains the actual authentication data, is of particular interest to the online application. This, or alternatively the data contained in this element, must therefore be extracted from the online application depending on the requirement. The data that is particularly relevant to identification of the user is highlighted in listing 5. Hence, besides the unique identifier (in this example obviously a bPK; for use in the private sector, the assertion would contain a wbPK), the SAML assertion also contains the first name, last name and date of birth of the authenticated person. This data can ultimately be drawn upon by the online application for unique identification of the user.

Listing 5: Example of a SAML response received from MOA-ID.

Please note: For applications in the private sector (private sector-specific Personal Identifier pssPIN), the online application should verify the plausibility of this assignment by comparing the personal data (name, date of birth) to the data put into the online application in addition to the unique identification term pssPIN. This is done to technically exclude incorrect assignments that are possible in the identity link signature in pssPIN applications from the manifest formation and treatment of the Source PIN/pssPIN (the personal data is always signed by the SourcePIN Register Authority despite the signature manifest). In addition, the login data signed by the citizen with a qualified signature (and thereby legal) can be archived for audit-compliant documentation of the login process (also see the following section regarding this).

Audit-compliant documentation

MOA-ID stores information on the login processes in a configurable log file, more or less detailed depending on the configured log level. For audit-compliant documentation of each individual login process, the online application can request the qualified signed login data of the citizen. In addition, the configuration of the online application in MOA-ID must have the attribute "provideAUTHBlock" set to the value "true". Listing 6 shows an example of a configuration of an online application in MOA-ID. In accordance with this configuration, the signed login data of the user is transferred to the online application via the SAML response.

Listing 6: Example of a configuration of an online application in MOA-ID.

MOA-ID supplies the signed login data together with the SAML assertion in the respective SAML response. Here, the signed authentication data is contained in the element "saml:SubjectConfirmationData". Listing 7 illustrates the integration of the signed authentication data in the SAML response. For reasons of clarity, the entire AUTH-Block is not shown.

Listing 7: SAML response with signed authentication data.

When storing authentication data obtained this way, you must observe that due to the nature of the electronic signature, the signed data must not be changed in any way during the course of the storage process because the signature would no longer be verifiable.


Signed releases

MOA-SP/SS/ID is provided as a signed release. This short documentation summarises how such a signed release can be verified. Here, a signed release consists of the following files (based on an example of a release in ZIP format - the description applies to other formats analogously):
  • [release].zip: This file contains the actual release
  • [release].zip.xml: This file contains the signed SHA1 hash value of the release file. An example of such a file can be seen in the following listing. Here, "7d2cc27b1d2bf08cc3882983911329ee6207419c" is the hash value of the release.

Listing 1: Signed SHA1 hash value of the files [release].zip.xml


The verification of the signed release is handled in three steps:

  1. calculation of the hash value of the release file
  2. verification of the signature of the hash value
  3. verification of whether the calculated hash value from (1) corresponds to the hash value from (2).

(1) Calculation of the hash value of the release

Calculate the SHA1 hash value of the downloaded release file ([release].zip). You can use a tool of your choice for this. The following tools are available as examples:

(2) Verification of the signature

Verification of the downloaded signature of the SHA1 hash value ([release].zip.xml). The easiest way to do this is via and the upload of the file ([release].zip.xml). After positive signature verification, you can go on to step 3.

The packages of the eGovernment open-source platform "" are signed with a certificate issued by "VeriSign Class 3 Code Signing 2010 CA" on A-SIT:
  • O = Centre for Secure Information Technology - Austria (A-SIT)
  • Serial Number: 76 df d2 0d 3c 2b 77 f1 dc e7 34 70 c4 5a 61 c2
  • Valid to: 20.11.2014

(3) Verification of the hash value

Afterwards, compare the SHA1 hash value from (1) that you calculated yourself with the signed hash value from (2). If the two values match, then it was possible to successfully verify the signed release and the release is trustworthy.

Scope of the signature

The signature merely confirms that the release is the release made available by the developers for the platform and it was not changed afterwards (integrity assurance of the release as it was created by the developers). The signature by S-SIT does not mean any warranty, guarantee of properties or liability with regard to the package.  Please also note the regulations given in the licenses of the individual packages.


This module facilitates the secure and unique identification and authentication of users who process online procedures with a Citizen Card. The authentication is carried out by using the qualified signature as well as the identity link of the Citizen Card and therefore has the highest level of security. With it, a login with the Citizen Card is possible to areas that have sensitive data stored. Examples of this are inspecting files and accounts, banking and transaction systems, as well as other areas in which personal data is stored.

MOA-ID can assign user-specific data from the identity link to a session as well as an sector specific personal identifier (ssPIN). In the process, both applications of government agencies or the private sector are supported.

MOA ID supports:
  • selection of the Citizen Card Environment (card or mobile phone signature)
  • communication with the browser and the Citizen Card Environment
  • adaptation of the design of the generated websites to the corporate identity of the organisation
  • secure and unique authentication of citizens or the government agency employees
  • calculation of the ssPIN
  • linking to the Supplementary Register for natural persons (SRnP) for the use of equivalent foreign identities
  • linking to the online mandates of the SourcePIN Register Authority
  • forwarding of the login data to downstream applications.
To achieve a uniform "look and feel" for citizens, a "template" is provided for the selection of the Citizen Card Environment. With a recognisable design of the logo, buttons and processes, it is supposed to be easy to use the Citizen Card in the different applications, because the design is the same despite the different Websites.

MOA-ID consists of an authentication and the optional proxy components. The authentication component ensures the authentication of the person and passes the login data to the downstream application. The downstream application takes over the login data by means of a call of the Web service interface of the authentication component.

The proxy component can also serve as the downstream application, which in this case can pass on the login data to the online application behind it. The proxy component facilitates an uncomplicated connection of existing online applications to the authentication component and hence to authentication with the Citizen Card. Both components can also be used on different computers. New eGovernment applications can also be simply setup so that the proxy component is not needed.

Representations are handled via the online mandate service of the SourcePIN Register Authority. Here, the representative chooses an existing mandate relationship on the service of the SourcePIN Register Authority. The application receives ssPIN or alternatively the name and date of birth of the representative and principal (legal or natural).

For legal professionals authorised for representation (e.g. lawyers or civil engineers) or alternatively for authorised professional representatives, a certificate enhancement in the Citizen Card can show the proxy characteristic. With it, the identification and authentication of party representatives is supported.


The functionality of MOA SP and MOA SS can be called both via the Web service interface (SOAP) as well as via an API. The Web service interface provides the possibility for clean separation of the calling application and the MOA components. Together with the multi-client capability of the design, this also offers the possibility of operating MOA centrally for multiple applications. In the specification, general requirements such as platforms, authentication, scalability, availability, logging, namespaces as well as the command format are defined.

Using the MOA-SS and MOS-SP modules:
  • Efficient service. Documents can be electronically signed in a customer friendly way, independent of the time and place, and legally and subsequently sent to the desired recipient over the Internet within seconds.
  • Easy use of the digital signature on electronic documents as a modern alternative to a handwritten signature on paper documents.
  • The origin and authenticity of electronically signed documents from government agencies that are sent over the Internet can be verified in an easy way. Forged documents can be recognised immediately, because the electronic signature is invalid.
The MOA-SP module encapsulates the entire functionality of the server-side signature verification, which applications need in connection with the use of Citizen Cards. Both signatures that conform to the Citizen Card specification as well as signatures that satisfy the XMLDSig and CMS standards are supported. They can be simple or qualified signatures. The query and reply mode is orientated around the commands of the Citizen Card specification. The interface consists of XML-based query and reply messages. The related XML schema is described in the MOA schema, which is contained in the specification suite. MOA-SP supports the XAdES and CAdES BES/EPES formats defined as a minimum in connection with the service guideline in a cross-border exchange.

The base module MOA-SS encapsulates the entire functionality of the server-side signature creation. Signatures that conform to the Citizen Card specification and also signatures in accordance with the SMLDSig standard can be created. Creation is only possible with software, but hardware security modules (HSM) are also supported. The process is broken down into the determination of the signature key, resolution of the data to be signed, calculation of the transformations and creation of the signature. Batch signatures can be carried out. In the process, multiple signatures are created with one command for multiple documents.

I am looking for...

... more detailed information on the flow of an MOA-ID login

... more detailed information on the integration of MOA-ID in my application

... more detailed information on the verification of a signed release