Guidelines Opens in a new windowissued by the Office of the Deputy Prime Minister of the Slovak Republic for Investments and Informatization (now the Ministry of Investments, Regional Development and Informatization of the Slovak Republic) on the basic obligations of public authorities under the e-Government Act.
Act No. 305/2013 Coll.Opens in a new window on e-Government (hereinafter referred to as the “e-Government Act”) defines the exercise of public authority as proceedings concerning the rights, legally protected interests and obligations of persons. In simple terms, this refers to procedures (activities) in which there is a clear relationship between a superior and a subordinate party. Therefore, the question is not whether an entity is a public authority as such, but whether it acts in that capacity in a particular proceeding.
An example would be proceedings under the Building Act in which a municipality acts as a building authority. If the outcome of its activities is, for example, spatial planning documentation, the municipality does not act as a superior party, does not have the status of a public authority in this particular context, and is therefore not obliged to follow the e-Government Act. Conversely, if the outcome of the proceedings is, for example, a decision on the location of a building (an individual administrative act conferring a right or imposing an obligation on a specific person), the municipality acts as a public authority and is obliged to comply with the e-Government Act.
There is no exhaustive list of public authorities. However, the following entities are considered to have the status of public authorities:
State Authorities
Municipalities / Towns / Self-Governing Regions
Public-Law Institutions
Natural Persons
The entire scope of notarial and bailiff activities is defined by law (the Enforcement Code and the Notarial Code) as the exercise of public authority. Notaries and bailiffs are therefore obliged to comply with the e-Government Act.
Legal Entities
Professional chambers (the Chamber of Notaries, Chamber of Bailiffs, Slovak Bar Association, Slovak Medical Chamber and other healthcare professional chambers) decide on the granting of “licences” based on conditions laid down by law (e.g. the Enforcement Code and the Notarial Code) and are therefore obliged to comply with the e-Government Act.
Schools and School Facilities Established on or After 1 January 2026
Schools and School Facilities Established by 31 December 2025
Their registration is governed by the rules previously in force:
Each entity may have only one electronic mailbox for each legal status. If the owner of an electronic mailbox simultaneously holds several different legal statuses, it should have a separate electronic mailbox established for each of those statuses.
Note: The National Agency for Network and Electronic Services is not authorised to assess whether an entity does or does not have the status of a public authority. To report the information required for establishing an electronic mailbox for a public authority, an application must be submitted using the relevant formOpens in a new window, in accordance with Decree No. 438/2019 Coll.Opens in a new window
Where the public authority is:
Examples
State Authority / Municipality / Town / Self-Governing Region
The Ministry of Finance of the Slovak Republic (MF SR) acts as a public authority in proceedings in which it carries out financial inspections pursuant to the Financial Control Act. At the same time, its civil service office acts in the capacity of an employer pursuant to the Civil Service Act.
In this case, only one electronic mailbox is established for the Ministry of Finance of the Slovak Republic in its capacity as a public authority. Even when it acts as an employer, documents are delivered to this same electronic mailbox. The applicable storage periods are those that would apply if it were acting as a public authority in its capacity as an employer.
Public-Law Institution (Schools, Health Insurance Companies, Social Insurance Agency)
At present, public-law institutions with their own legal personality are provided with two electronic mailboxes:
Electronic mailboxes established for public-law institutions in their capacity as public authorities are activated for the receipt of electronic deliveries upon the first login to the mailbox, but no later than the tenth day following the date of its establishment.
On the tenth day after the electronic mailbox has been established, the public authority becomes accessible in the “Find a Service” section and is assigned the “General Agenda” service. This service enables natural persons and legal entities to submit electronic filings, such as applications, complaints, statements and similar submissions.
The electronic mailbox established for a public-law institution in its capacity as a legal entity is used to receive documents and decisions issued by other public authorities in proceedings relating to activities in which the institution acts as a legal entity (e.g. in its capacity as an employer).
The electronic mailbox of a legal entity that is not registered in the Commercial Register of the Slovak Republic is automatically activated for the receipt of electronic deliveries as of 1 May 2018.
It is at the discretion of the public authority to decide whether it considers it necessary to establish electronic mailboxes for its branches. However, it is essential that persons subject to the relevant legal obligations be able to submit documents to such organisational units in proceedings in which public authority is exercised directly by a branch of the public authority. For example, if the Social Insurance Agency, as a public authority, has only one electronic mailbox and ensures that submissions addressed to its branches are forwarded to the relevant branches, the purpose of the legislation is fulfilled. It is therefore not necessary for each branch of the Social Insurance Agency to have its own electronic mailbox.
The same approach applies to the Office of the Prosecutor General, the Police Force, labour offices, tax offices at regional and district levels, and cases where a single founder or establishing authority has several schools under its remit.
They are subject to these obligations to the extent that they exercise public authority, for example, when exercising statutory powers and making decisions on the rights and obligations of individuals in the field of public health insurance. In other matters, they do not act as public authorities but merely as ordinary legal entities. Consequently, the obligations applicable to them under the Act are limited (e.g. automatic activation of an electronic mailbox for the receipt of documents, the requirement to obtain eID cards to access such mailboxes, etc.).
A public authority may provide electronic filing office functionality itself by implementing an electronic filing office system within its own information system and connecting it to the processing of messages delivered to its electronic mailbox.
However, a public authority may also use the functionality of the central electronic filing office module of the ÚPVS (Central Government Portal). This module ensures that messages delivered to the public authority's electronic mailbox are processed in accordance with the requirements of the Act, on behalf of the relevant public authority. It is up to the public authority itself to decide which option to use. However, these two options are mutually exclusive.
An electronic filing office and an electronic mailbox are two different things.
An electronic mailbox is similar to a physical postbox into which the postman delivers mail. However, the electronic mailbox does not process the mail any further. This is precisely the purpose of the electronic filing office, which generates delivery receipts for submissions addressed to the public authority and also serves as the entry point into the records management system and the subsequent processing workflows of the relevant authority.
At present, a public authority may decide for itself whether to establish its own filing office or use the central electronic filing office. Both solutions involve certain financial costs and human resource requirements.
We would also like to point out that Amendment No. 238/2017 Coll. to the e-Government Act introduced, with effect from 1 November 2017, a transitional period during which public authorities may continue using their own electronic filing offices and adapt their information systems for the mandatory use of the central electronic filing office module (after 31 December 2020).
The exemptions provided for in Section 10(13) and (14) of the e-Government Act may also be applied during the transitional period.
Guaranteed conversion is a technical process whereby the content of an original document is transformed into a newly created document in a different format (from paper to electronic format or vice versa). The resulting document may be used for the same legal purposes as the original document.
A document converted in accordance with the e-Government Act may be handled in exactly the same way as a document in its original format. This significantly improves, for example, the speed of communication, reduces the storage space required for archiving, and increases the speed with which documents can be accessed.
Guaranteed conversion is not the same as ordinary scanning or printing. Its primary purpose is to make it possible to use a document in its transformed format for electronic communication with public authorities, while providing safeguards comparable to those applicable to the official certification of signatures.
Further information about guaranteed conversion is available on the website of the Ministry of Investments, Regional Development and Informatization of the Slovak Republic.Opens in a new window
As a general rule, the obligation for public authorities to use the Central Electronic Official Notice Board (CUET) has been in force since 1 November 2016. Under the e-Government Act, public authorities (including municipalities) are required to use shared modules when exercising public authority. The CUET solution forms part of the module referred to in Section 10(3)(f).Opens in a new window In other words, if a public authority has an integration with the shared modules of the ÚPVS (Central Government Portal), it should have access to the functionality for publishing information on the CUET.
At present, a public authority is required to publish on the CUET, on a one-to-one basis, everything that it publishes on its physical official notice board.
As of 1 January 2018, the Regulatory Authority for Electronic Communications and Postal Services has also been required to publish on the electronic official notice board everything it publishes in its official gazette. Such publication is for information purposes only.
Pursuant to Sections 8 and 9 of Act No. 272/2016 Opens in a new windowColl. on Trust Services, a mandate certificate issued to a natural person authorised to act on behalf of a public authority does not contain personal data such as the individual's birth identification number or residential address.
The mandatory attributes are the first name and surname of the authorised person and the identification number of their identity document (identity card or another document, such as an employee ID card). The mandatory details of the authorised person are subsequently displayed and made available in the electronic mailbox environment on the Central Public Administration Portal.
A qualified electronic seal can be created on the Central Public Administration Portal (ÚPVS) using a key pair stored in the ÚPVS HSM module in the following ways: by integrating with the Central Electronic Filing Office (CEP), or via the slovensko.sk portal, in the message composer within the public authority's electronic mailbox, using the "Seal" button.
Instructions on using a qualified electronic seal in the message composer are published on the slovensko.sk portal under the title "Joint Authorisation of Electronic Documents by Public Authorities on the slovensko.sk PortalOpens in a new window".
Electronic documents can also be authorised using a qualified electronic seal through an external certified device (smart card, USB token, etc., i.e. not through the ÚPVS HSM module). Such products are provided by individual qualified trust service providers. The list of providers is published by the National Security Authority.Opens in a new window
Under the e-Government Act, an activated electronic mailbox is the designated channel for electronic delivery. A foreign natural person or legal entity may apply for an electronic mailbox to be established. Applications for the establishment of electronic mailboxes for foreign entities must include certain mandatory attributes, such as the name and registered address of the legal entity and its identifier. For this purpose, pursuant to Section 3(n)(3) of the e-Government Act, an identifier means an organisation identification number or an equivalent number or other identifier assigned or determined for the purpose of unambiguous identification under the laws of the country in which the entity has its registered office or place of business. In the case of a natural person, pursuant to Section 3(n)(1) of the e-Government Act, the identifier means a number equivalent to a birth identification number or another identifier assigned to the individual for the purpose of unambiguous identification under the laws of the country of which the individual is a citizen, together with their first name and surname.
If a foreign person logs in to the slovensko.sk portal via an eIDAS Node (currently, this login method is available only to natural persons holding a German identity card or a residence permit issued to a foreign national residing in Germany), the person's details are transferred from the eIDAS Node to the Identity and Access Management (IAM) system upon their first login, and an electronic mailbox is created for them. The electronic mailbox is not automatically activated for the delivery of documents. However, the foreign person may activate it themselves.
If a foreign natural person or legal entity does not have an electronic mailbox established on the slovensko.sk portal and activated for the delivery of documents, official decisions must be delivered to them in paper form.
The Central Electronic Filing Office (CEP) does not support the automated verification or display of signatures and objects contained within individual externally signed data objects (so-called nested signatures or nested signature containers).
The Central Electronic Filing Office supports the creation and verification of signatures for the formats specified in its documentation.Opens in a new window
Within the electronic mailbox environment, the "Verify Signatures" function can be used to display the relationships between signatures and signed documents, including multiple signatures.
In the case of multiply nested signatures and containers, the file must be manually downloaded from the signature container and subsequently verified manually using the verification service, or manually extracted.
For example, if a nested ASiC container located inside another ASiC container needs to be extracted, the nested ASiC file must first be downloaded and then extracted, for example, by attaching it to a message in the message composer or by using an application such as D.Viewer.
In the case of PDF files signed directly using a PAdES signature, the ÚPVS environment allows users to download the PDF file as a whole. It does not provide an option to extract the individual versions of the PDF file corresponding to the versions that existed when each signature was applied.
To obtain a specific version of a PDF file signed with a particular signature (i.e. a PDF file without information added through subsequent signatures or modifications), we recommend using specialised applications such as Adobe Reader.
Documents must comply with the requirements set out in the standards forming part of Decree No. 78/2020Opens in a new window Coll. on Standards for Information Technologies in Public Administration (the ITVS Standards Decree).
Pursuant to Decree No. 78/2020 Coll. on Standards for Information Technologies in Public Administration, entities subject to this decree are required to use, in particular, the PDF format when sending or publishing text documents, provided that the recipient is not expected to make further modifications to the document and also in cases where the text document contains graphics.
All attachments to official decisions that are in PDF format and are electronically signed or sealed must, in accordance with the Decree on IT Standards for Public Administration, be in one of the following formats: PDF/A-1, PDF/A-2 or PDF/A-3. This ensures that the documents are displayed correctly.
Until 30 June 2017, the validity of authorisations in XAdES_ZEP and ZEPf formats within the Central Electronic Filing Office was conditional upon signed PDF files complying with the PDF/A-1a format, as assessed by a proprietary validator using specific validation criteria. This validator also classified certain compliant PDF/A files as invalid, which could result in a valid authorisation being incorrectly assessed as invalid.
As of 1 July 2017, PDF file validation no longer affects the validity of an authorisation in the Central Electronic Filing OfficeOpens in a new window, and this validator is used by the Central Electronic Filing Office for informational purposes only. Support for the reference validator VeraPDF is currently being prepared.
The same information is also stated as follows:
Until 30 June 2017, the validity of authorisations in XAdES_ZEP and ZEPf formats within the Central Electronic Filing Office was conditional upon the validity of signed PDF files against the PDF/A-1a format, as assessed by a proprietary validator using specific validation criteria. This validator also classified certain valid PDF/A files as invalid, which could result in a valid authorisation being incorrectly assessed as invalid.
As of 1 July 2017, PDF file validation no longer affects the validity of an authorisation in the Central Electronic Filing OfficeOpens in a new window, and this validator is used by the Central Electronic Filing Office for informational purposes only. Support for the reference validator VeraPDF is currently being prepared.
Practical example of a situation that may arise:
When technical information is displayed in the signature verification results, users may be confused by an indication that the object validation has failed, i.e. that the signed document does not comply with the relevant format specification.
However, the result of the object validation has no impact whatsoever on the validity of the authorisation and may not be accurate due to the specific validators being used. The information that is essential for determining the validity of the authorisation is the information indicating whether the electronic signature is valid.
Under the currently effective Decree No. 78/2020 Coll. on Standards for Information Technologies in Public Administration (available hereOpens in a new window), public administration authorities are obliged to accept signed PDF files in versions other than PDF/A-1a as well.
This means that if the object is marked as invalid in the object validation results section of the signature verification report, this does not affect the validity of the authorisation.
The Central Electronic Filing Office performs informational validation only for certain file formats and only for certain signature formats. Further details are provided in the Central Electronic Filing Office documentationOpens in a new window
A public authority may communicate with another public authority (provided that neither of them is acting in the capacity of a party to proceedings) by using the ÚPVS Process Integration and Data Integration Module (once it is fully operational) or through direct electronic communication.
It may also use the automated functions of information systems, such as access to the relevant registers, etc.
However, this must not involve the electronic delivery of submissions or decisions in cases where the use of electronic mailboxes is mandatory. This applies, for example, where a public authority is a party to proceedings conducted by another public authority.
In certain cases, the Central Government Portal (Ústredný portál verejnej správy – ÚPVS) evaluates authorizations in ZEPf (.zep) and XAdES_ZEP (.xzep) files, which, under the legislation effective from 15 October 2015, should generally no longer be created, as invalid.
This may occur, for example, when the authorized electronic document is in a format other than:
Up-to-date information on accepted formats is available in the documentation of the Central Electronic Filing OfficeOpens in a new window.
One example is an authorization marked as invalid with validation result code No. 110. In such cases, one of the available certified products must be used to validate the authorization instead of the authorization validation service provided by the ÚPVS.
As of 1 July 2017, an incompatibility was resolved on the slovensko.sk portal concerning the validation of electronic documents in PDF/A-1, PDF 1.3 and PDF 1.4 (.pdf) formats signed using ZEPf (.zep) or XAdES_ZEP (.xzep) files.
Until 30 June 2017, the authorization of electronic documents in PDF/A-1, PDF 1.3 and PDF 1.4 formats contained in ZEPf (.zep) and XAdES_ZEP (.xzep) files was evaluated by the ÚPVS as invalid if the authorized document was found to be non-compliant with the PDF/A-1a specification. In such cases, validation result codes No. 2104 and 2105 were returned.
Alignment of the ÚPVS with Regulation (EU) No. 910/2014Opens in a new window of the European Parliament and of the Council (eIDAS Regulation) and with the technical specifications for electronic signatures set out in Commission Implementing Decision (EU) 2015/1506Opens in a new window will be implemented in the subsequent period.
Examples of authorization validation results:
Case No. 1:
"Authorization validation status: Invalid"
"Validation result code: 110"
"Validation result description: Validation of the signed data objects failed."
Case No. 2:
"Authorization validation status: Invalid"
"Validation result code: 2105"
"Validation result description: Error when assessing compliance with the PDF/A-1 specification."
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*
As of 1 July 2017, the incompatibility concerning the validation of electronic documents in PDF/A-1, PDF 1.3 and PDF 1.4 (.pdf) formats signed using ZEPf (.zep) or XAdES_ZEP (.xzep) files was resolved on the slovensko.sk portal.
Consequently, the authorization validation result generated by the Central Government Portal from 1 July 2017 onwards may differ, in the case of the aforementioned PDF formats, from the result generated up to 30 June 2017.
Until 30 June 2017, the authorization of electronic documents in PDF/A-1, PDF 1.3 and PDF 1.4 formats contained in ZEPf (.zep) and XAdES_ZEP (.xzep) files was evaluated by the ÚPVS as invalid if the authorized document was found to be non-compliant with the PDF/A-1a specification. In such cases, validation result code No. 110, 2104 or 2105 was displayed in the authorization validation report, as indicated in the separate **notice entitled Incorrect Authorization Validation.
**
Users are hereby advised that, in certain cases, the Central Government Portal evaluates authorizations in signed ZEPf (.zep) and XAdES_ZEP (.xzep) files, which, under the legislation effective from 15 October 2015, should generally no longer be created, as invalid.
This applies to cases where the authorized electronic document is in a format other than .pdf (PDF/A-1a), .txt, .png or .xml (XMLDataContainer), which are described in detail in Section 57a(a) to (d) of Decree No. 55/2014 Coll. on Standards for Information Systems of Public Administration, or where the document is in a format that the ÚPVS evaluates as invalid.
Examples include authorizations marked as invalid with validation result code No. 110, 2104 or 2105 (see examples above). In such cases, one of the available certified products must be used to validate the authorization instead of the authorization validation service provided by the ÚPVS.
The resolution of incompatibilities in the validation of authorizations by the ÚPVS involving older ZEPf (.zep) and XAdES_ZEP (.xzep) formats, as well as incompatibilities with other signature-creation applications when validating file formats, was planned for the following months.
Based on the conclusions of the working groups of the Commission for Standardization of Public Administration Information Systems of the Office of the Deputy Prime Minister of the Slovak Republic, plans included establishing a unified reference validator for PDF/A files for the Slovak public administration, as well as providing more detailed guidance on the rules for accepting and validating file formats. These measures were intended to eliminate compatibility issues and problems with authorization validation.
Files containing electronic signatures or seals may use various file extensions. However, the file extension itself does not guarantee that the file is actually signed.
To determine whether a file has been signed with a valid qualified electronic signature or sealed with a valid qualified electronic seal, a signature validation service must be used. An informational validation service is available on slovensko.sk.
Files containing electronic signatures may include the following types:
Signature containers created in accordance with the legislation effective from 1 July 2016 – Commission Implementing Decision (EU) No. 2015/1506:Opens in a new window
Signature containers created under Slovak rules effective until 30 June 2016, or after that date where all parties involved in the relevant communication have mutually agreed to their use:
Electronic documents that contain signatures as part of the document itself:
These signatures are currently not supported by the Central Electronic Filing Office.
Electronic signatures that contain the electronic documents they sign as part of the signature itself:
These signatures are currently not supported by the Central Electronic Filing Office.
Electronic signatures separated from the electronic documents they sign:
Time stamps separated from the electronic documents to which they relate:
- Time stamps use the extension: .tst
Electronic documents signed or sealed within signature containers or as part of electronic signatures may use various file formats, such as .pdf, .txt or .png.
Public authorities are required to accept and create electronic document formats prescribed by Decree No. 78/2020 Coll. on Standards for Information Technologies in Public Administration of the Slovak Republic.
Validation of XAdES enveloping (.xml), XAdES enveloped (.xml), CAdES enveloping (.p7m) electronic signatures and seals, as well as standalone document time stamps (.tst), is currently not fully supported by the ÚPVS.
Therefore, a different signature validation service must be used for these formats.
Detached signatures, which are separate from the signed electronic documents (.p7s, .xml), can currently only be processed and validated by the ÚPVS when included in a signature container.
Further details on the signature formats supported by the ÚPVS can be found in the documentation describing the functionality of the Central Electronic Filing Office.Opens in a new window
The mandatory formats of qualified electronic signatures and seals, as well as the mandatory formats of signature containers, are specified in a separate document issued by the National Security Authority (NBÚ)Opens in a new window and derive from Regulation (EU) No 910/2014 Opens in a new windowof the European Parliament and of the Council and Commission Implementing Decision (EU) No 2015/1506Opens in a new window. These formats are XAdES, CAdES, PAdES and ASiC, the usual file extensions of which are listed in the previous question.
Before this legislation entered into force, the following formats were also defined in the Slovak Republic: XAdES_ZEP (.xzep, .zepx) and ZEPf (.zep). These were also listed for information purposes in the NBÚ standardsOpens in a new window applicable until 30 June 2016.
According to the NBÚ statementOpens in a new window [.pdf, 383.6 kB], after this date public authorities are no longer obliged to accept the XAdES_ZEP (.xzep, .zepx) format, as this format imposes requirements beyond those specified in the Annex to Commission Implementing Decision (EU) No 2015/1506.
With regard to the ZEPf (.zep) format, public authorities are obliged, according to the NBÚ statement Opens in a new window[.pdf, 383.6 kB], to accept a CAdES (or possibly XAdES) signature, as it complies with the Annex to Commission Implementing Decision (EU) No 2015/1506. Such a signature can be validated as a standalone signature of an .eml file (containing Base64-encoded files), or embedded in an ASiC container and validated as an ASiC container in accordance with Regulation (EU) No 910/2014 of the European Parliament and of the Council.
Under the applicable legislation, the XAdES_ZEP (.xzep, .zepx) format and ZEPf (.zep) containers should no longer be created. Pursuant to Section 14(3) of Act No 272/2016 Coll., a public authority may be subject to a penalty for creating a signature or seal in a format that does not comply with Commission Implementing Decision (EU) No 2015/1506.
A file signed with a qualified electronic signature or bearing a qualified electronic seal does not necessarily have to contain a visual representation of a handwritten signature or stamp.
To verify whether a file has been electronically signed, it is necessary to use an application or service designed for processing and verifying electronic signatures.
The informational signature verificationOpens in a new window function is available for documents contained in electronic messages through the features of electronic mailboxes. A public signature verification service can also be used for informational verification.
The slovensko.sk website supports informational verification of electronic document signatures only in certain formats. To verify signatures in other file formats, we recommend using other available certified tools.
Electronically signed documents are transmitted primarily in specific signature or signature-container formats, which require specialised software to open.
Electronic mailboxes on the Central Government Portal (ÚPVS) allow users to:
These functions are available by selecting "View", "Download" or "Download unsigned content" after clicking the three-dot menu next to the file in an electronic message.
Please note that when using the "Download unsigned content" function, the resulting file does not contain the electronic signature.
For PDF files signed directly using a PAdES signature, a standard PDF reader can be used to view the document.
The "Open in D.Viewer" option has been removed from the menu in the new electronic mailbox. It has been replaced by advanced features available directly in the electronic mailbox, providing detailed information about signatures, the relationship between signatures and documents, and signature containers.
The D.Viewer application can still be used by downloading and opening the signed file on a computer. However, D.Viewer only displays information about signatures and their relationship to documents. It does not allow users to verify the validity of signatures or display data completed using most electronic forms.
To view files without using the electronic mailbox functionality, users can also use the standalone D.Viewer application for MS Windows, available on the "Software applications for downloadOpens in a new window" page, or its Java version for MS Windows, macOS X and GNU/Linux, as well as other applications developed by third-party providers.
The XAdES_ZEP (.xzep, .zepx) and ZEPf (.zep) formats, which originated in the Slovak Republic before Regulation No 910/2014Opens in a new window entered into force, are not used outside Slovakia and may not be accepted by other EU Member States.
When exercising public authority electronically, the director, mayor or other authorised person signs decisions using a mandate certificate or authorises them using a qualified electronic seal. They therefore do not use their personal qualified certificate stored on their eID (electronic identity card with a chip).
In practice, the following rules apply:
Related information:
The Central Electronic Registry (CEP – Centrálna elektronická podateľňa) already provides a service for the joint electronic authorisation of electronic documents. This service is available once the relevant public authority has been integrated with CEP.
This means that the functionality can be used through the information system of the public authority, which integrates with CEP and invokes its services.
Further instructions for service providers using the Central Government Portal (ÚPVS) are available on the NASES website and in the integration manuals published on the Partner Framework PortalOpens in a new window, under the section Integration with ÚPVS, subsection Public Authorities (OVM).
The option to jointly authorise multiple documents by public authorities is also available on the Central Government Portal as a user interface function when completing electronic forms or when composing a message in an electronic mailbox.
For further information, please refer to the Guides for InstitutionsOpens in a new window section and the guide entitled Joint Authorisation of Electronic Documents by Public Authorities.
It follows from Section 28(6) Opens in a new windowof the e-Government Act that it is possible, for example, to create decisions consisting of data entered in an electronic form together with a PDF file, provided that both are jointly authorised.
It is therefore not permissible to authorise the PDF file separately from the data entered in the electronic form.
At the same time, the data entered in the electronic form must form an integral part of the electronic official document. In other words, it cannot serve merely as an accompanying letter.
In accordance with Decree No. 78/2020 Coll. on Standards for Information Technology in Public AdministrationOpens in a new window, every electronic form must contain the following components:
The file names in the Content/ directory are not prescribed. The names listed above are generated by Form Designer, but alternative names may also be used.
For technical details, please refer to Annex 1 of the Decree on Standards and the Guide to Form Registration and Management.Opens in a new window
These values are used in the font-weight attribute in XSL/XSLT files.
For the Arial, Helvetica and Georgia fonts, weights other than 400 and 700 should not be used. The attributes normal and bold should be used instead.
The following alternatives are available for Arial:
These combinations of values are specified using the font-family, font-style and font-weight attributes in the XSL/XSLT file.
We recommend using standard settings, fonts and recommended parameters in electronic forms, as outlined above. Any non-standard fonts must be embedded in the XSLT transformations.
Note:
Pursuant to Section 2.6.8 of Annex 1 to Decree No. 78/2020 Coll. on Standards for Information Technology in Public Administration, when using the XSL-FO markup language, the first font specified for rendering must be Arial, Times New Roman or Courier New.
Other fonts are not available for generating the print representation in PDF format (using the Download as PDF function in the electronic mailbox).
During preliminary or full signature verification (so-called asynchronous verification), which is automatically sent to the electronic mailbox of a public authority (OVM) if the Central Electronic Registry (CEP) is configured as its registry office, the value of the mimetype attribute in the Object element of the electronic message determines the format of the object being verified.
If the value of the mimetype attribute in the electronic message does not correspond to the actual file format of the object in the Object element, the signatures cannot be verified. The result is an Unverifiable status and an error message.
The prescribed supported values for the mimetype attribute are published in the Central Electronic Registry Functionality Documentation.Opens in a new window
The value of the mimetype attribute, as defined by Ministry of Finance Decree No. MF/009269/2014-173 on the Uniform Format of Electronic Messages, specifies the data format of the object.
When signature verification is manually initiated for a specific message object via the "..." menu in the electronic mailbox on the Central Government Portal (ÚPVS – slovensko.sk), the synchronous CEP service Informative Verification 3 is automatically invoked.
When verifying signatures on an individual object (i.e. not the entire MessageContainer), this service currently does not take the mimetype value into account. Instead, it sequentially attempts verification using all available verification mechanisms:
If any of these verification mechanisms detects the presence of a signature, the verification result is displayed. If no signature is detected, the service displays a corresponding notification.
For performance reasons, CEP currently cannot be configured to ignore the mimetype value during preliminary and full verification automatically sent to electronic mailboxes and to attempt verification using all available verification mechanisms instead.
It should also be noted that, from the perspective of legal validity, there is no difference between preliminary/full asynchronous verification and synchronous verification (whether initiated manually in the electronic mailbox or by invoking the service through system integration), provided that the final verification result is conclusive — i.e. it does not contain a status such as Provisionally valid.
Under the e-Government Act, the ÚPVS is required to provide for the creation of electronic messages for the purposes of electronic official communication in a uniform format. This format is defined by Decree No. MF/009269/2014-173 on the Uniform Format of Electronic Messages. The National Agency for Network and Electronic Services (NASES) therefore ensures the creation, sending and delivery of electronic messages that meet the requirements laid down in the aforementioned decree.
In view of the above, certain legally prescribed requirements for electronic messages are automatically checked by the ÚPVS. Electronic messages that do not meet the requirements prescribed by legislation may not be successfully delivered to the recipient. In such cases, the sender is automatically notified by means of an error message. However, the system does not automatically send an error notification to the sender in the event of a failed delivery if the error is specific or if the system fails to detect it due to the non-standard content of the message.
Examples of situations in which successful delivery of a message may not take place:
A signature verification result is also sent for messages containing electronic official documents or electronic submissions that do not contain signed files, in the case of public authorities using the Central Electronic Filing Office of the Central Public Administration Portal. Signature verification results are also sent for messages that do not contain signed documents.
Why does a message contain a signature without a timestamp, even though the signature verification result indicates that a timestamp is present?
Public authorities that use the Central Electronic Filing Office as their electronic filing office receive, in their electronic mailbox, a signature verification result as part of the service for registering a received submission or electronic official document. This result is included in the delivered message in the form of a technical Sk-Talk message with the class SIGN_VERIFY_RESULT.
When registering a received message, the Central Electronic Filing Office adds a qualified electronic timestamp to its internal records for signatures that do not contain one.
This qualified electronic timestamp is subsequently used during signature verification as reliable evidence of the time at which the signature existed. Consequently, the signature verification result sent to the public authority's electronic mailbox contains information about the qualified electronic timestamp.
Since the qualified electronic timestamp is not added directly to the message during registration, the signature in the message remains in its original state as submitted. Therefore, when using the "Verify Signature" function in the electronic mailbox, or when saving a signed file from the message to a computer and subsequently verifying its signature, the result will indicate that no timestamp is present.
The qualified electronic timestamp is not added directly to the signature in the electronic message. Instead, it is stored internally within the Central Electronic Filing Office (CEP). This is because adding it directly to the electronic message would alter the message's digital fingerprint recorded in the delivery receipt.
Currently, the ÚPVS does not provide a service for retrieving the timestamp stored exclusively in these internal CEP records.
When creating a qualified electronic signature (see “Creating a Qualified Electronic Signature”) through the slovensko.sk portal, a qualified electronic timestamp is automatically attached to the signature in the message composer once successful signing has been confirmed in the D.Signer/XAdES application.
If a user attaches an already-signed electronic document to a submission and the signature does not contain a timestamp, the portal does not add a qualified electronic timestamp to that signature.
If a handwritten signature is insufficient to authorise the document under the applicable legislation and a formally certified signature is required, a user who already has a signed document without a qualified electronic timestamp may obtain one by creating a signature through the portal or by using the services of another service provider to add the qualified electronic timestamp.
The failure to display the content of a document in the electronic mailbox may be caused by:
In the graphical interface of the electronic mailbox on the Central Public Administration Portal, a file extension is automatically added to the file name for files that have no extension or have an incorrect extension. The extension is added according to the principles set out in the portal’s technical information on functionality.Opens in a new window
When the D.Viewer application is used to open or save a signed file without an extension, a file extension is automatically added only for basic file formats, based on the MIME type value.
The technical functionality rules for the electronic mailbox are set out in the document “Documentation on the Functionality of the Electronic MailboxOpens in a new window” [PDF, 886.1 kB].
Further information about the functions and documents available in connection with the obligation to use joint authorization of electronic documents in cases where the procedure under Section 28(6) or Section 36 of the e-Government Act applies, as well as the option provided for in Section 28(3), can be found in the article Joint Authorization Opens in a new windowon the ÚPVS portal.
As of 1 September 2019, pursuant to Section 23(3)Opens in a new window of the e-Government Act, a public authority must use a qualified electronic signature created using a mandate certificate to authorize a document intended for use abroad. This signature must be accompanied by a qualified electronic seal and a qualified electronic time stamp.
Attaching a qualified electronic seal to an already existing qualified electronic signature constitutes the authorization of the same document using two different authorization methods (in accordance with the eIDAS RegulationOpens in a new window).
In practice, this type of authorization can be performed in the following ways:
This problem, in which signed files are marked as unsigned, is caused either by the sender's information system or by an incorrectly formatted file (e.g. .asice, .asics, .xzep, .zepx, .zep, or .pdf).
As a result, the user is not given the option to validate the signatures in the electronic mailbox, and the Central Electronic Mailroom does not send the signature validation results to the mailbox of the public authority.
The problem occurs mainly when the sender's information system fails to detect signatures in attached files and, consequently, does not mark the files transmitted within the electronic message data structure with the attribute IsSigned="true". Instead, it specifies IsSigned="false".
In such cases, under the annex to Decree No. 385/2022 Coll.Opens in a new window, the file is considered unsigned and is reported as such in the signature validation results sent by the Central Electronic Mailroom to the recipient's electronic mailbox.
The decree states:
“The value of this attribute is always decisive, regardless of whether the file is actually signed.”
Public authorities are required to create electronic messages in accordance with the uniform electronic message format specified by Act No. 305/2013 Coll. on e-Government and Decree No. 385/2022 Coll. on the uniform format of electronic messages and electronic delivery receipts.
When signatures are validated using the publicly available synchronous Informative Signature Validation service on the slovensko.sk websiteOpens in a new window, signatures within each file are automatically searched for and detected. If signatures are successfully detected, informative signature validation is performed.
Technically, this differs from sending signed documents as part of electronic messages to an electronic mailbox. Under the decree, signature detection is not performed in that process unless the document is marked with the attribute IsSigned="true" in the electronic message data structure.
