Austria Overview - RUB-NDS/FutureTrust GitHub Wiki

The Austrian eID has been introduced in 2003 with first mass rollouts in 2005. Even if called “Bürgerkarte” (Citizen Card) which might indicate a card-based system, it is technology-neutral. Current implementations include smartcard tokens by various issuers and mobile ID solutions. It is a voluntary system for the citizens. Currently, there are about 750 thousand active mobile IDs, 40 thousand health insurance cards activated with an eID option, and 80 thousand profession cards (lawyers, notaries, pharmacists, public servants, etc.). The eID is free of charge for the citizen; relying parties from public and private sector can use it for authentication at their services free of charge.

Technical specifics of the Austrian eID are that it is tightly bound to qualified electronic signatures (the authentication process includes signing a human-readable authentication record)^[1]. Thus, each Austrian eID also holds a qualified certificate, which gives synergies to FutureTrust’s scope on electronic signatures and trust lists. Further specifics of the Austrian eID are that identification is sector-specific for data protection reasons (i.e. different unique identifiers are cryptographically derived for each sector of state activity like tax, health, education, etc., for each private sector relying party, respectively) and that the Austrian eID also supports electronic mandates and representation through query of authoritative sources (like the Company Register).

The Austrian eID service is based on different eID means: mobile ID or smartcards with tokens issued by the public sector or the private sector (see Austria Authentication Methods for details of the various eID means). What all Austrian eID means have in common is that each is a qualified signature-creation device (QSCD) capable of qualified signatures and each store a so-called identity link. The identity link is a SAML record electronically signed by the source PIN register authority (the Austrian Data Protection Authority which is the authority in charge of the eID system). It is created upon eID issuance and links the qualified certificate to a source personal identifier (source-PIN) which is a citizen’s unique identifier that is cryptographically derived from a Central Population Register identifier. Identification is based on sector-specific identifiers – during the authentication process a different person identifier is cryptographically derived for each sector of state activity (like health, tax, education), for each private sector organization, respectively.

The Austrian eID system is browser-based. Integration of the eID means with a service is through an open source module “MOA-ID” (module for online application – identification) that is operated by the service provider. MOA-ID basically provides two interfaces, one controlling the eID tokens and one interfacing to the service:

• The interface to the citizen’s eID token is through an HTTP-based interface that either is provided by the mobile ID service provider or, for smartcard eIDs, through a software running at the citizen’s PC. The software environment providing this HTTP interface is referred to as “Bürgerkartenumgebung” (BKU).
• The interface to the service provider is either SAML (SAML 2.0 for the majority of services, SAML 1 for a few older legacy application), OAuth is offered as well.

A SAML authentication process is as follows (cf. the sequence diagram in Figure 1):

1. The citizen aims to access a protected resource of a service or clicks some “login” link.
2. The service launched a SAML authentication request to MOA-ID.
3. A session handle is created and the service provider’s request is validated.
4. An eID means selector (mobile ID or smartcard ID) gets presented to the citizen.
5. The citizen selects the eID means which identifies the URL of the HTTP eID middleware “BKU” (running at the citizen PC for smartcards or operated by the mobile ID service).
6. MOA-ID redirects to the eID middleware “BKU”.
7. MOA-ID requests the identity link by passing a service’s sector identifier (e.g. “SA” for tax), the eID middleware BKU cryptographically derives the sector-specific identifier (basically, a hash function is applied to the source-PIN and the sector identifier).
8. An authentication block is displayed to the citizen containing: the service provider requesting authentication, its sector identifier (or organization identifier for private sector providers), the citizen’s personal data requested (name, date of birth, sector-specific identifier) and some process data (date, time, URL the response will be redirected to).
9. The citizen consents by applying a qualified signature to this authentication data.
10. MOA-ID validates the citizen’s qualified signature, validates the signature on the identity link containing the sector-specific identifier, and verifies the link between the identifier and the signature certificate expressed by the identity link.
11. A SAML assertion is created and the SAML authentication response is returned in response to the request issued by the service provider in step 2.

Figure 1: Message flow for the Austrian eID

1. ^ Austrian Citizen Card (2014) Technical Specification version 1.2. (2014). https://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114-en/