Translations of this page:

Citizen's portal and public administration portal

The Citizen's Portal refers to the transactional part of the Public Administration Portal available at, where the client/citizen can make submissions to the public administration and use its services through self-service under his/her guaranteed electronic identity. The services of the citizen's portal take over all the services of CzechPOINT@home, which was designed for citizens who do not want to go to the Czech POINT contact point for a statement from the register and have their own data box of a natural person. The applicant's data box is used for sending the application and for delivering the issued extract from the register or other reply.

In the case of the Citizen Portal, as part of the Public Administration Portal, the citizen stands as a self-service user "outside" the public administration and the portal provides him/her with one universal entry point inside. For this reason, all subject (agenda) and, in the future, local portals with their services are federated "under" this central portal. The federation is at the different levels thatál citizen supports:

  • Federation Single sing-on
    • Providing connectivity through a single electronic identity, which is implemented by the National Identity Authority system. The Citizen Portal only publishes information (link) on which address the federated portal is located.
  • Federation with data provision
    • Providing federation through a single electronic identity, which is implemented by the National Identity Authority system. The Citizen Portal has an interactive section that actively provides data from its scope.
  • Federation with service handling
    • Providing federation through a single electronic identity, which is implemented by the National Identity Authority system. The entire service is published on the Citizen Portal, including the necessary forms and logic required for processing.

The Citizen Portal uses the services of the linked data pool for its functionality, as well as the services of the National Identity Authority. From the perspective of the linked data pool, the Citizen Portal is one of the reader AIS that has the mandate under the A344 agenda to display to the right holder his information held about him by the public administration. The Citizen's Portal in this must ensure that the agenda under which it is governed is constantly updated as the services and portals providing the data are progressively expanded. Technically, the Citizen Portal is connected as a reader AIS to the eGON Service Bus system, through which it draws data published by agendas using so-called contexts. In this, the Citizen Portal only needs to periodically update the drawn list of contexts of other agencies. From the point of view of a National Identity Authority, the Citizen Portal is a service provider pumping guaranteed identification and authentication services.

Both the Citizen Portal and the Public Administration Portal are centrally provided and operated portals. Integration or federation of services of the authority can be done through custom solutions in the form of agency portals, territory portals or private data users. Integration is at 3 levels in total:

  1. Prokliklik to a custom solution using Single Sign-On. It includes only a custom space on the citizen portal where the authority publishes its information tile through which the client gets, using the principle of Single Sign-On and involvement in the national identity space, to a custom solution
  2. Providing data to its own space on the citizen portal. In addition to the ability to click through to the custom solution involved in the national identity space, it also includes always up-to-date client data provided through the linked dataset
  3. Complete solution of the public administration service on the citizen portal using a form-based solution with all the integrations in points 1 and 2.

A user login is required to access the Citizen Portal. The chosen login method also determines the range of services that are accessible to the user. The login page of the Citizen Portal is available at Login is possible:

  • via a qualified electronic identification system (NIA) in accordance with Act No. 250/2017 Coll., on electronic identification, using an ID card with an electronic part (only ID cards issued from 1 July 2018, no registration required) or using the identification means Name, password and SMS (registration required), or using other means of identification.
  • via the authentication interface of the Data Box Information System in accordance with Act No. 300/2008 Coll., on electronic acts and authorised document conversion. Only the following types of subjects - data box holders - can log in:
    • natural person (FO)
    • natural person doing business (PFO)

Only data boxes established on request, not by law, can be used, i.e. not those established automatically for lawyers, statutory auditors, tax advisors or insolvency administrators. All login options are independent of each other, but to fully use all services of the Citizen's Portal, it is recommended to use an electronic ID card and to have a data box connected. In both cases, this is access with a guaranteed identity in accordance with Act No. 365/2000 Coll, on public administration information systems and on amendments to certain other acts, in other words, access to a public administration information system or an electronic application using a means of electronic identification, at the time of its issue or in connection with it or in connection with enabling its use, the identity of a person has been verified by a state authority, a body of a territorial self-government unit or a public authority which is not a state authority or a body of a territorial self-government unit, or which has been issued within a qualified electronic identification system.

The Citizen Portal stores persistently the following type of information:

  • BSI (meaningless directional identifiers) - this is a whole set of identifiers used to communicate with surrounding systems (e.g. AIFO - ISZR, SePP - NIA, etc.). These identifiers have the meaning of a foreign key. No information about the user can be read directly from their value (mostly GUIDs). These identifiers do not leave the perimeter of the PO except when communicating with the system concerned.
  • Settings - this is information that affects the information displayed on the Citizen Portal (e.g. tile display, notification settings, etc.). No information about the user can be read directly from their values.
  • Documents - these are a number of "files" that are created in the Citizen Portal or uploaded to the PO by the user. These are, for example, a printable form of submission, an archive of the PO, etc. These documents are stored in a special secure area that is only "unlocked" when the user logs in. These documents may also contain special categories of personal data (previously known as sensitive data), but they are "invisible" from the PO's point of view (the Citizen Portal does not parse these documents).
  • Communication attributes - currently these are email and phone number. Communication attributes do not leave the perimeter of the Citizen Portal directly, but are only used to establish communication between the Citizen Portal and the user, or to send notifications. The Citizen Portal notifies the user only in case of his request in specific cases (settings).

A lot of user information passes through the Citizen Portal transiently. Its breadth cannot be specified precisely - it depends on which AIS the user communicates with via the Citizen Portal. However, this information is not stored (it is only an online preview of the information). As far as the notification of changes to the data in the basic registers is concerned, the process is triggered at defined times (Citizen Portal configuration), the Citizen Portal detects changes to the registered AIFOs in the basic registers. If such a change has taken place and the user has set up a notification, the PO creates a message (according to the user's settings) and stores it in the message list queue.

By frontend communication we mean primarily the sharing of the common space of a qualified electronic identification system (NIA). In this space, the user has the possibility to navigate through individual portal solutions and to use the so-called 'single sign-on' principle, i.e. a single sign-on shared between all portals or applications. The NIA is governed by the provisions of Act No. 250/2017 Coll., on electronic identification. In connection with the above, the so-called static tiles on the Citizen Portal are used to transition the user between the Citizen Portal and other portals or applications without the need for further authentication. The Citizen Portal thus serves as a signpost in terms of the functionality of static tiles. Currently, the user of the Citizen Portal selects and activates services (in the form of tiles) from the catalogue. In the next phases of development it is considered to offer relevant tiles according to their content and the roles in which the user will act. Active services in the form of tiles are displayed to the user on the Citizen Portal dashboard.

By default, the Citizen Portal communicates directly with only a limited number of systems, namely centrally shared services. Specifically:

  • The basic registry information system through its own or composite services,
  • The information system of data boxes.

For communication with other systems, the Citizen Portal exclusively uses the eGon Service Bus / Information Shared Service System.

Communication via ISZR

  • Reading from Basic registers (ROB, ROS):
    • access to data in basic registers is done in an agenda activity (RPP) used by the reader;
    • the activity must have permission to access Basic registries.
  • Reading via composite services (AIS EO):
    • reading via composite services is done in the agenda activity (RPP) used by the reader;
    • the activity must have permission to read from AIS.
    • the activity must have permission to read from the ROB according to the type of service used (AIFO verification or reference data used for search).

Directly called services include e.g. E03 robCtiAifo (reading reference data from the ROB registry), E22 rosCtiData, E45 orgConsentAifo (registering the AIFO to notify changes in the ROB and ORG to the calling AIS), E98 iszrCtiSouborCiselniku, E106 rppListAgend, E153 iszrProcessFormular, E181 robWriteConsentProvided, E199 orgZjistiAis (identifying AIFO/Agenda combinations in which an AIFO corresponding to the input AIFO exists in the ORG) or E226 eidentityCtiAifo (converting a meaningless natural person identifier to the corresponding AIFO of the AIS).

Communication via eGSB/ISSS

When we talk about collaborating via the back-end, we mean connecting the Citizen Portal to the publishing AIS and collaborating via services that are exposed on eGSB/ISSS. Connecting the publishing AIS is quite complex in terms of complexity and requires cooperation from the eGSB/ISSS operator. Its inputs are especially necessary in defining contexts (data message schemas), which are indeed the responsibility of the publisher, but in order to maintain a consistent format across all publishers, approval from the eGSB/ISSS operator is required. The citizen portal does not consume all the data that is published on eGSB/ISSS, if only because not everything is intended for a natural person user. Therefore, the choice of what and how to display on the Citizen Portal is the result of a specific cooperation between the AIS publishing manager and the Citizen Portal. After agreeing on the scope of services, the Citizen Portal developers proceed in the following steps:

  1. development for reading data (reader application),
  2. authorisations for reading and obtaining test data,
  3. reading data testing.

After verifying the availability of eGSB/ISSS, the Citizen Portal downloads the necessary WSDL and XSD service definitions and contexts for the available publishing AIS from the service catalog. Based on these files unique to each publication AIS and the general description of the eGSB/ISSS services described in the document "Use of eGSB/ISSS services by reader AIS", the Citizen Portal will create its own web services client interface for reading data using eGSB/ISSS.

Enter your comment: