The Citizen's Portal refers to the transactional part of the Public Administration Portal available at https://www.portal.gov.cz/, 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 https://www.portal.gov.cz/Portál citizen supports:
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:
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 https://obcan.portal.gov.cz. Login is possible:
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:
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:
For communication with other systems, the Citizen Portal exclusively uses the eGon Service Bus / Information Shared Service System.
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).
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:
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.