On the following page you will find more information on the minimum EfA requirements for the implementation of the online services.
The defined framework conditions in the context of "surface design and design" focus on the provision and display of online services in the frontend.
In principle, two key approaches can be distinguished:
The specific wording of the EfA minimum requirements for "surface design and design" can be found below:
⁇ No. ⁇ Requirement ⁇
| --- | ----------- |
⁇ 001 ⁇ The online service MUST have a neutral (no country, local or authority-specific style guides or the complete appearance of the interface of the respective administrative portals of the participating countries, municipalities or authorities) design. |
⁇ 002 ⁇ The online service SHOULD have a design tested with users and take into account the guidelines on the user experience portal network. |
⁇ 003 ⁇ The online service, after the performance-specific responsibility feature (e.g. postcode, location or geo-referenced data or parameter handover in case of online service call) has been determined, MUST display the individual competent authority with the contact details and SHOULD display the respective coat of arms of the competent local authority, if it has been deposited by it. |
The online service MUST be able to identify the authority responsible for receiving the application using the LeiKa ID and regional key from the current database of the portal network. |
Online services that are provided for EfA co-use must comply with all technical requirements and in particular with federal law and must therefore be legally secure. This requires the minimum requirements for the so-called "technical logic". In addition, provision must also be made for technical parameterization, i.e. adaptation, to the specific provisions of Land law of the respective co-benefiting federal state.
⁇ No. ⁇ Requirement ⁇
|---|---|
⁇ 001 ⁇ The online service MUST comply with the technical requirements of the federal laws. |
⁇ 002 ⁇ The online service MUST take into account additional requirements under Land law of all post-user countries. |
⁇ 003 ⁇ The online service SHOULD, if necessary, be able to take appropriate account of state or statutory implementing regulations on federally regulated services (e.g. through multi-tenancy, parameterization). |
A "data exchange standard" regulates the format of a uniform sending and receiving of data. In the field of digitalisation of public administration, the data exchange standards XÖV and Xfall/XData Fields prevail in particular. The corresponding interfaces of affected applications, such as specialist procedures, must therefore be able to receive and process the data of an online service in the specified format (connectivity). Data exchange standards are developed with a legal-technical reference as so-called "technical standards".
The EfA minimum requirements regulate the criteria for standardized data transmission in this area. In principle, a standard-compliant XML file must be delivered via a routing system, which can be further processed via an interface in a specialist procedure. However, if no technical standard exists yet, but is to be developed in the future, the first step is the delivery of a PDF file, which includes all application data to be transmitted.
More in-depth information on applicable XÖV standards can be found here, for example. They are prepared, supervised and further developed by the Coordination Office for IT Standards (KoSIT).
The specific wording of the EfA minimum requirements for "technical logic" can be found below:
⁇ No. ⁇ Requirement ⁇
|---|---|
⁇ DS1 ⁇ The online service MUST output the target data in a standardised XML format (e.g. as a module within a XÖV standard or the XData fields in an XFall container) via an automated interface, which can in turn be read (semi-) automatically by specialist procedures. If there are no technical procedures, the online service should (in addition) generate a readable PDF file. |
If there is no technical standard, a standardization process for the data interface MUST be set up to ensure the following aspects: predictability, reliability, liability, financing; governance by the public administration; involvement of all relevant stakeholders; Openness of standards in the sense of the Free Software Foundation Europe; practical orientation; regular further development (change management – not only in the case of changes to the legal bases, but also based on feedback from practice); high level of detail, high quality, technically robust; appropriate object of standardisation; proven maturity of the methodology/framework; appropriate consideration of EU requirements and offers. |
⁇ DS3 ⁇ The online service MUST generate a structured output of the application in XFall format based on the associated FIM master data schemas, provided that no technical standard exists or is created in the administration (e.g. XÖV). |
The online service should be compatible with the most widely used technical procedures of different manufacturers (if any) in the countries to be connected according to the EfA principle. |
In order to be able to exchange data between online services and competent authorities, an appropriate and as uniform a means of transmission as possible should be chosen. This is regulated by the so-called EfA minimum requirements for "routing and transport". The methods used should be chosen according to their criteria of ease of connection, degree of dissemination and time availability.
The following technology stacks are considered:
**Transfer with OCSI / XTA and obtain routing information via DVDV **
The OSCI (Online Services Computer Interface) transport protocol sets a binding standard for authenticated message transmission by the public administration. Multi-level encryption and electronic signature ensure that messages / documents sent cannot be changed and meet the high need for protection. In order to ensure a secure transmission of the requested data, an intermediary is intermediate. The intermediary enables the OSCI-compliant transmission of the data. Its task is to check and forward incoming messages. XTA is a transport and transmission procedure for exchanging messages between the various specialist procedures.
**Transmission via FitConnect interface **
As part of the provision of application data via the "FIT-Connect" routing system, the respective networks are served by means of an XTA routing protocol. FITKO takes over the delivery service and provides the countries with the forms for collection. For this purpose, the respective countries should find the appropriate specialist authority via a delivery application and with the help of the organizational keys and address it to the specialist client. After decryption, the client provides the completed form to the technical procedure.
Within the framework of EfA, applications can be submitted by different countries in different countries. Based on the DEST-ID (Destination-ID), the target networks can be found. The specialist authorities are found via a DVDV query. The delivery application should deliver the application data to the correct specialist procedure via direct communication with the specialist client.
The delivery application can be carried out independently of FITKO in the respective countries. Countries provide the delivery application. In doing so, FITKO must ensure access to every country. In order for the EfA online service to be accessible from every country and for everyone, the higher-level delivery takes place via FITKO. The provision to the technical procedure currently requires a national solution. The solution is to be implemented by an application through a client-server relationship. MWIKE is already working with its service providers on a universal solution.
You can find detailed explanations of FIT-Connect here.
The specific wording of the EfA minimum requirements for "routing and transport" can be found in the following list:
⁇ No. ⁇ Requirement ⁇
|---|---|
⁇ DS1 ⁇ The technical connection data of the competent authorities can be stored and maintained directly in the online service for a small number of nationwide receiving agencies (less than 16).
⁇ DS2 ⁇ The online service MUST determine the technical address of a larger number of nationwide receiving agencies (>16) by accessing the DVDV.
When routing using the DVDV, a DVDV registration concept MUST be created for the online service.
The online service MUST be able to send the data to be transported via an OSCI transmitter (possibly via an XTA interface to the transmitter) in encrypted form to the OSCI receivers defined by the request processing authorities. If there are already nationally established transmission standards (e.g. Elster) in individual domains, these can be used provided that the protection objectives of confidentiality, integrity (including authenticity) and availability are ensured.
The online service MUST enable a certificate-based transmission of the data with end-to-end encryption. Encryption MUST reach at least one endpoint to be defined by the post-user authority. The certificates used must originate from the administrative PKI. |
Note: In the future, FIT-Connect can be used provided that the protection objectives of confidentiality, integrity (including authenticity) and availability are ensured and the corresponding conditions are created.
An interoperable "user account" must be connected to the online service in order to authenticate and identify the applicant. Until all user accounts are interoperable, at least the federal user account for citizens or the uniform corporate account MUST be connected.
Two interoperable user accounts have already been successfully connected for the WSP.NRW to register citizens, traders and companies. For companies (single companies, partnerships, corporations) and associations, the portal and associated account ‘My Business Account’ has been created, which unifies nationwide communication between companies and institutions. The connection is made via ELSTER/NEZO. The authentication options offered are:
Registration via ELSTER is also possible for private individuals.
In the case of private individuals, a low-threshold offer is also offered with a user account that is more tailored to private individuals. The Servicekonto.NRW of the CIO NRW, introduced by Governikus AG in 2017, provides access to digital administrative services in the federal state of NRW for applicants and can therefore also be used by residents of other federal states.
The authentication options offered are:
As part of the further development of Governikus AG’s ‘service account’ product, on which the service account.NRW is based, the OpenID functionality has been extended to technically enable cross-border logins. For example, the federal states of Hamburg, Bremen, Saxony-Anhalt, Schleswig-Holstein and the BUND user account are already integrated into the ‘service account’.
The specific wording of the EfA minimum requirements for "user account" can be found below:
No. Requirements Requirements
|---|---|
⁇ NK1 ⁇ An interoperable user account MUST be connected to the online service. Until all user accounts are interoperable, at least the federal user account for citizens or the uniform corporate account MUST be connected.
The EfA online services should be able to call a payment component to be provided by the receiving authorities in a parameterised manner for the payment of a fee, provided that this component and its parameters are provided by the receiving authority. In addition, the online service can also offer its own payment component, which can be configured by authorities that do not have their own payment component.
In principle, the WSP-NRW offers the possibility of connecting parameterized payment components and calling them up. In NRW, there is already a separate payment component for all responsible bodies (e.g. municipalities, individual authorities) are provided and deployed. This is the payment platform “E-Payment-Developer-Community of the Federal Government and the Länder” (ePayBL) under the technical direction of the Free State of Saxony.
The specially developed "fee module" of the WSP.NRW allows fee rates as well as different payment scenarios (upstream", "downstream" and "mixed types") to be entered for the competent authorities per procedure.
Since the IT Planning Council does not yet have a parameterizable nationwide payment interface, it is also possible to connect country-specific payment components, provided that the necessary information for integration into/to the WSP.NRW is provided here.
In the near future, it is intended to use a nationwide payment interface if it is approved and developed by the IT Planning Council.
The specific wording of the EfA minimum requirements for "technical logic" can be found below:
⁇ No. Required Requirement ⁇
|---|---|
⁇ P1 ⁇ The online service SHALL be able to call a payment component to be provided by the receiving authorities parameterized for the payment of a fee, provided that this component and its parameters are provided by the receiving authority.
⁇ P2 ⁇ The online service CAN also offer its own payment component, which can be configured by authorities that do not have their own payment component.
By providing the online services in the FIT store, we enable uncomplicated legal co-use. It is provided by linking contractual relationships according to the Software-as-a-Service (SaaS) model. FITKO acts as an intermediary and concludes a SaaS contract with both sides in its own name. An individual SaaS post-utilisation contract is concluded with each post-utilisation state.
The post-utilisation state informs FITKO of its interest in co-use by means of letters of interest, and FITKO contacts the implementing state. The implementing and post-utilising federal states then clarify the respective details in a voting letter and inform FITKO accordingly. This voting letter will become part of both SaaS contracts.
The possibilities of legal re-use are summarised below:
FIT Store
In the FIT store, EfA services are provided through a chain of contractual relationships. FITKO acts here as an intermediary and is a direct contractual partner (provider and buyer at the same time). The re-use is carried out by the countries, which in turn can pass on the purchased online services within the country, as regulated in the contract details.
Administrative agreement
An individual design of administrative agreements is possible. The program management has provided a blueprint for this purpose.
Inter-public agreement
The procurement law intermediaries in the Länder agree on the exchange of services via the Interpublic Agreement (IOA). Here, the intermediaries bundle the exchange of services in the federal state. The FITKO is also part of the IöV, so an exchange to the FIT store is possible. This is a tried-and-tested model, which, however, aims to be reused by the municipalities. This is not a solution for the subsequent use of chamber services, provided that the intermediaries do not pass on the online services to the chambers.
Open marketplace
The IT Planning Council (IT-PLR) has decided to set up a digital marketplace for administrative services and has commissioned govdigital eG to do so. Clients can offer online services on the marketplace, which can then be reused via a chain of in-house awards. The exact design is currently still open.
The specific wording of the EfA minimum requirements for the "legal reuse option" can be found here:
No. Requirements Requirements
|---|---|
⁇ R1 ⁇ The responsible country MUST offer an appropriate legal sharing option for services in the state enforcement and transferred sphere of influence (e.g. administrative agreement, FIT store).
⁇ R2 ⁇ The responsible country MUST have sufficient license rights for the online service for use by other countries and municipalities. |
The specific wording of the EfA minimum requirements for "organisation" can be found below:
⁇ No. ⁇ Requirement ⁇
|---|---|
For the online service, an organizational cooperation structure MUST be created (or an existing one used) in which the participating countries continuously maintain the professional, legal, technical, etc. requirements.
This website uses cookies. Some cookies are technically necessary, others are used to analyze user behavior in order to optimize the offer. You can find an explanation of the cookies used in our Privacy Policy. You can also find further information in our Imprint.