Technical dimension of the Co-Use Alliance

Already in 2021, the implementation of the EfA minimum requirements began - from the technical point of view of WSP.NRW / GovForms, these could already be implemented to a large extent. Therefore, the basis for a technical connection of interested partners has been created and detailed planning for pilot implementation takes place immediately.

Supported transport formats by GovForms 2.0:

• FIT-Connect (recommendation): ready for use

Communication with the responsible authorities can already be done via Fit-Connect. A functional interface is available on the WSP.NRW side

• Native OSCI/XTA2 implementation: in preparation

The FIT-Connect platform commissioned by the IT Planning Council serves the networking and integration of IT systems of the federal IT architecture and is suitable for connecting online portals and competent bodies in the sense of EfA implementation. The advantage of FIT-Connect lies in the high level of abstraction compared to other realizations of transport routes between the federal states, authorities, municipalities and portals. FIT-Connect uses existing infrastructure and processes such as DVDV and OSCI. FITKO provides its own infrastructure, parameter maintenance services and APIs.

NRW is currently working on the creation of an adapter ("connector") to enable media-break-free receipt of structured application data even without specialist procedures.

Security with OSCI

With the encryption method OSCI (Online Services Computer Interface) a binding standard for authenticated message transmission of the public administration is set. Multi-level encryption and electronic signature ensure that messages / documents sent cannot be changed and meet the high need for protection.

Multi-level encryption and electronic signatures ensure that messages/documents sent cannot be changed and meet the high need for protection. An intermediary is involved to ensure secure transmission of the requested data.

The intermediary enables the transmission of the data in accordance with OSCI. Its task is to check and forward incoming messages.

There are two different keys, which are referred to as envelopes under OSCI procedures:

• Outer envelope = Usage data
• Inner envelope = encrypted content data

In the inner envelope, the content data is encrypted with the recipient's public key. This ensures that this data can only be decrypted and read by the recipient.

The outer envelope contains only usage data (transport information).

The intermediary only opens the outer envelope data to identify the recipient of the message. The OSCI protocol used ensures the security and integrity of the data.

Data transport via XTA/2

XTA is a transport and transmission procedure for exchanging messages between the different technical procedures. The XTA standard usually consists of different modules:

• Model of roles and responsibilities ("role model")
• Service profiles

There are two different ways for co-users to integrate online services into their own portals:

1. Connection via a parameterized link

With this type of connection, it is sufficient for the calling portal to call a predetermined link with the corresponding parameters, e.g. https://service.wirtschaft.nrw/?a=1;b=2;c=3. No further adjustments have to be made, the embedding is then done e.g. via Iframe

2. Integration of a complete package via so-called "Web Components" with the provision of code snippets

The integration of the online services in another portal takes place via webcomponent, where HTML fragments, scripts and a separate DOM (Shadow-DOM) are inserted as an independent resource. This is completely customizable by CSS and the respective CI of the calling portal can be completely adopted.

By connecting the user accounts "Servicekonto.NRW" and the ELSTER "Company Account", it is possible for citizens and entrepreneurs nationwide to carry out secure authentication with the respective stored data on the online portal.

Different levels of trust are possible, depending on the chosen authentication method:

The WSP.NRW thus meets the requirements of EfA co-use with regard to user accounts. Although in both cases these are interoperable accounts that can be connected to other country-specific accounts, it will also be possible in the future to connect the BUND user account to the WSP.NRW in order to enable European citizens to register and authenticate using eIDAS.

The online services of the WSP.NRW must meet all federal and state legal requirements. For this purpose, the technical legal requirements are implemented in the "digitalization lines" as part of various process steps.

[A description of the organizational and process model of the "digitalization roads" can be found here.](/help/efa/post-utilization/wsp-nrw/approach-of-digitalization roads/)

In principle, however, the WSP.NRW's digitization roads are geared towards developing services that are as uniform as possible across Germany in order to achieve the goals of nationwide CSO implementation as quickly as possible. Insofar as this is not legally possible, the services within the scope of the digitization roads (see above) are parameterized professionally and adapted to the respective technical requirements.

In the context of technical parameterization and multi-client capability, the WSP.NRW's micro-service architecture also sets the course for providing parameterized services to the countries.

Transfer parameters within the scope of the form call

If a form is called up as part of shared use and embedded in another online portal, the geoinformation (PLZ, ARS, AGZ), the LeiKa ID and a client identification must be provided as start parameters. The LeiKA-ID and the geoinformation serve to identify further authority-specific parameters and to provide the correct form. The client identification serves to assign the client-specific parameters.

⁇ Parameter ⁇ Description ⁇
|-------|-------|
⁇ LEIKA key ⁇ Identifies the performance ⁇
⁇ Mandate ID ⁇ Identifies the calling portal ⁇
⁇ Target information ⁇ Geoinformation (ARS, AGS, ZIP) to identify the authority ⁇

Client-specific parameters in GovForms 2.0

Within the scope of multi-tenancy and parameterization, the aim is to display an online service that is adapted to the technical requirements of the respective country and assigned to it on a subject-based basis (example: User accesses the portal of the co-beneficiary state, uses a service of the WSP.NRW, but submits the application in another co-beneficiary state). A multi-tenant, technological basis therefore makes it possible to make individual adjustments to interfaces, processes and representations, depending on the federal state and the competent authority.

For clients, specific form adjustments and own texts for fees and legal bases can be stored. In addition, further technical interface information on the payment interface, return channel and transport procedures is persisted at the client level.

⁇ Parameter ⁇ Description ⁇
|---|---|
⁇ Form customizations* ⁇ Individual form configurations: (limited content) Adaptation of forms to country-specific conditions
⁇ Legislative texts ⁇ Individual insertion of texts in forms (e.g. provincial laws) ⁇
⁇ Return address (?) ⁇ Set specific return channel and mailboxes for notifications etc. ⁇
⁇ Payment interface ⁇ The parameters and technical address for calling the selected payment component ⁇
⁇ Transport channel ⁇ Deposit of the corresponding transport channel (OCSI/XTA, FIT-Connect) ⁇

*Customer-specific form adjustments should only be carried out to a limited extent (e.g. on the basis of legal requirements) in order not to undermine the principle of EfA use.

Parameters via directory services

Technical parameters for addressing applications to competent authorities are in principle stored in the DVDV directory. This data includes technical routing information as necessary certificates. Furthermore, further information such as contact details, addresses as well as fee rates and settlement accounts per LeiKa and body can be determined via the DVDV. Furthermore, the portal network of the online gateway is also available via the XZuFi standard and, if FIT-Connect is used, the FIT-Connect self-service portal. GovForms 2.0 can access these directories and complete necessary parameters.

⁇ Parameter ⁇ Description ⁇
|---|---|
Depending on the selected transport method (XTA2, FIT-Connect), the routing information (destination address, intermediary, DestinationID, public key certificates) is determined. |
⁇ Coat of Arms / Logos ⁇ Planned is a possible provision for display in the form ⁇
⁇ Addresses / Contact details ⁇ To display the address and contact information of the competent body ⁇
⁇ Payment Parameters ⁇ Individual Fees, Settlement Accounts per LeiKa and Competent Body. |

The WSP.NRW is already able to connect various payment components to the portal and make them usable for citizens. Thus, even today advance payment of fees can be carried out component-independently.

Individual payments are possible as soon as corresponding parameters (accounts, fee amount) are delivered to the WSP-NRW via a return channel. These parameters can be stored e.g. in the [German administrative services directory] (https://www.itzbund.de/DE/itloesungen/standardloesungen/dvdv/dvdv.html) (DVDV). The platform ePayBL, which will offer a complete parameterization by Q1/2023, is suitable as a future standard component for Germany.

In addition to ePayBL, alternative payment interfaces can also be used, provided that the interface parameters are known and have been stored for the client.

Three different payment models can be offered:

1. Upstream payments

In the case of upstream payments, the fee flat rates deposited in the DVDV are invoiced directly after the submission of an application and can be paid electronically by the user. The amount of the fee depends on the chosen service and the responsible body or the applicable fee regulations.

2. Downstream payments

In the case of downstream payments, the fee will be invoiced as a result of the work performed. In this case, a return channel is necessary to address the fees to the user without media disruption. Here, for example, a payment request could be sent to the mailbox, which in turn contains a parameterizable link to the payment interface.

3. Type-mixed payments

In this case, the payment consists of an upstream lump sum and a subsequent cost-based calculation.

The concrete EfA co-use of a process from NRW for other federal states can be implemented within the framework of pilots. In this way, open questions can be answered directly and interpretations can be prevented.

• Individual, selected services (LeiKas) or bundles of services (technically related services) can be implemented as part of a pilot.
• The piloting serves as a technical breakthrough - based on the specified technical framework parameters, an implementation of the selected service(s) with participating competent bodies is sought. Based on the experience gained, rollouts in the country involved in the piloting can be planned to a greater extent and further services can be implemented.

The self-service portal (SSP) is used to prepare for EfA sharing of online services implemented by MWIKE. The implementation of the SSP has taken place within the WSP.NRW and can be achieved with a separately provided login. In particular, the SSP is to be used for the direct answering of already clarified questions and the transmission of requirements (technical and technical) and thus to support communication with the countries to be connected, which seek to share the EfA online services of MWIKE.

The self-service portal offers, among other things, administrative functions, whereby client-specific (clients are understood to mean all institutions interested in co-users) information can be managed by the countries themselves without the need for a live support employee.