Jusletter IT

Bereits im Jahr 2001 haben Layne/Lee die wissenschaftlichen Grundlagen, die implizit auch das Once-Only-Prinzip (OOP)¹ beinhalten, gelegt. In ihrem wegweisenden Artikel über E-Government Developing fully functional E-government: A four stage model² beschreiben sie die horizontale Integration der E-Government-Lösungen („Horizontal Integration“), also die Integration von (IT-)Systemen über verschiedene Funktionen der Verwaltungen und die Etablierung eines echten One-Stop-Shops für Bürger*innen (und folglich auch Unternehmen). Dafür wurde ein vierstufiges Implementierungsmodell entwickelt, das noch heute in seinen Grundaussagen Gültigkeit aufweist. Seitdem wurde das System erweitert, aber die Eckpfeiler wurden schon damals verankert. Das OOP kann als One-Stop-Shop gesehen werden, bis hin zum No-Stop-Shop, und es stellt ein prominentes und aktuelles Thema der digitalen öffentlichen Verwaltung dar. Zudem repräsentiert das OOP eine wichtige Säule der europäischen Single Digital Gateway Verordnung (SDGR), die bis Ende 2023 europaweit umgesetzt werden sein soll.³ Zur Umsetzung der SDGR bedarf es die Möglichkeit der Auffindbarkeit von Daten (in SDGR: Evidenzen) in Verwaltungsregistern und Datenquellen über Landesgrenzen hinweg; und natürlich die Mechanismen, die die Zugänglichkeit und Adressierbarkeit zu den Daten mit sich bringen. Auch die Qualitätssicherung der ausgetauschten Daten ist besonders hervorzuheben In begleitenden europäischen Projekten und Programmen sollen nicht nur die Voraussetzungen, sondern auch die Umsetzung der SDGR vorbereitet werden.

Das EU-Projekt Digital Europe for All⁴, ein wissenschaftsorientiertes Projekt des Instruments Research- and Innovation-Action (RIA)⁵, wurde im Januar 2020 gestartet. Es führt bestimmte technische bestehende Konzepte des OOP in Europa weiter (z.B. aus TOOP⁶ oder CEF⁷) und zielt auf die Vorbereitung der Umsetzung der SDGR ab. Wissenschaftliches Ziel ist es, eine vertiefende Forschung, und dem folgend auch die Anwendungen, in den beiden herausfordernden Bereichen der technischen Abbildung von Vertrauen (Trust) sowie der Semantischen Interoperabilität im Projekt zu erarbeiten. Das Bestreben von DE4A ist, einen ganzheitlichen und flexiblen europäischen (technischen) Ansatz zu verfolgen, um die Vorteile eines sicheren und Benutzer*innen-zentrierten Austauschs von Once-Only-Daten über auf Standards basierende verteilte digitale Services zu demonstrieren. Demzufolge wird in drei Pilotbereichen die Umsetzung in realitätsnahen Online-Verfahren in den pilotierenden Mitgliedstaaten angestrebt. Ein besonderer Schwerpunkt im Projekt liegt zudem auf der Bewertung der Anwendbarkeit der entwickelten IT-Systeme sowie der Evaluierung des konkreten Nutzens (Nachhaltigkeit). Neue Technologieanwendungen, wie die Blockchain und die Methoden des Machine Learning werden hierbei mitbetrachtet. Österreich ist im Pilotbereich Doing Business Abroad involviert und demonstriert die automatisierte Registrierung im österreichischen Unternehmensserviceportal (USP)⁸ von europäischen Unternehmen aus den Niederlanden, Rumänien und Schweden. Dabei wird sowohl auf die Implementierung der eIDAS-Identifikation von natürlichen und juristischen Personen (inkl. Vertretung) fokussiert und zudem das OOP für die Nutzung in den Partnerländern verfügbarer Daten umgesetzt.

EU-Projekte sind immer herausfordernde Vorhaben, vor allem, wenn sie sowohl gewichtige Forschungsschwerpunkte aufweisen, aber auch realitätsnahe Umsetzungen anvisieren. Zudem liegen die spezifischen Herausforderungen des Projekts in der Tatsache, dass es eine europäische Verordnung begleitet, die selbst erst in ihrer inhaltlichen Ausformung begriffen ist.⁹ In Bezug auf das Projekt DE4A lässt sich als Vorteil erwähnen, dass technische Konzepte bereits vorlagen, die von voranlaufenden Projekten übernommen werden konnten, so sind technische Anwendungen, wie z.B. das AS4-Gateway (Access Point), bereits seit mehreren Jahren in europäischen Interoperabilitätsvorhaben produktiv im Einsatz.

Im Folgenden soll ein Überblick über die einzelnen Bereiche beschrieben werden.

Das Projekt DE4A startete vor dem Vorliegen des OOTS, viele technische Konzepte, so z.B. die OOTS-Architektur, konnten daher nur antizipiert werden. Das betraf auch die Ausformungen der technischen Architektur. Diese legt jedoch eine wichtige Grundlage für alle technischen Entwicklungen im Projekt, nicht zuletzt auch der Piloten. Demzufolge wurden verschiedene Varianten entwickelt, die in drei Pattern formuliert wurden und die auch in einem jeweiligen Pilotbereich Anwendung finden:¹⁰

• Intermediation Pattern: Wird im Doing Business Abroad-Pilot angewendet; alle Benutzer*innenzentrierten Prozesse finden auf der Seite des Datenkonsumenten (in SDGR-Terminologie: Data Requester, DR) statt.
• User Supported Intermediation Pattern: Wird sowohl im Moving Abroad- wie auch im Studying Abroad-Pilot Pilot angewendet; die meisten Benutzer*innen-zentrierten Prozesse, finden auf der Seite des Datenkonsumenten statt, jedoch findet der Geschäftsprozess des Previews auf Seite des Datenübermittlers (in SDGR-Termonologie: Data Provider, DP) statt, was eine Übergabe des/der Benutzer*in von DR zu DP (und anschließend wieder retour) mit sich bringt
• Verifiable Credential Pattern: Wird im Studying Abroad-Pilot angewendet, hier wird über den Austausch von gesicherten Attributen und unter Einsatz von Blockchain-Technologie der Austausch von Daten/Evidenzen sehr stark Benutzer*innen-zentriert abgehandelt.

Zusätzlich werden zu einem späteren Zeitpunkt der Pilotierung (siehe unten) zusätzliche Pattern entwickelt, die sich für die jeweiligen Ausbauschritte eignen, so zum Beispiel ein abgeschlankter Lookup Pattern oder der Subscription and Notification Pattern, die beide im Doing Business Abroad-Piloten angewendet werden.

Der semantische Forschungsschwerpunkt in DE4A beschäftigt sich mit mehreren technischen Konzepten, die den strukturierten Datenaustausch ermöglichen. Der semantische Rahmen von DE4A umfasst drei Hauptbereiche: ein Information Exchange Model (IEM), den technischen Information-Desk (IDK), sowie die pilotspezifischen Ontologien.¹¹ Das IEM liefert die Spezifikation der Nachrichtenausformung, die zwischen den zuständigen Behörden ausgetauscht werden. Das IEM ist unabhängig von der technischen Implementierung und entsprechend dem DE4A-Projekt spezifisch ausgeformt auf den jeweiligen Pilotbedarf und der zugrundeliegenden Architektur (den Pattern). Das IEM berücksichtigt auch bestehende Konzepte, so z.B. TOOP EDM¹² und andere nationale Modelle.

Der IDK bietet Informationen für den DR und den DP, die für einen reibungslosen grenzüberschreitenden Austausch von Daten/Evidenzen im Rahmen von DE4A erforderlich sind. Der IDK besteht aus folgenden Kernkomponenten, [1] einen Service, das den DR unterstützt, die ausstellende Behörde, die in einem bestimmten Land die erforderlichen Daten/Evidenzen erbringen kann zu finden (Issuing Authority Locator); [2] einen Service, das den DR unterstützt, die Organisation zu finden, um Daten/Evidenzen von einer bestimmten ausstellenden Behörde zu beziehen; [3] ein Ontologie Repository, das hilft, die Bedeutung kanonischer Beweisattribute zu verstehen; sowie [4] eine Komponente für den Preview, die dem/der Benutzer*in die Daten/Evidenzen zur Freigabe der Weiternutzung in dem öffentlichen Verfahren oder Prozess für das er/sie die Daten/Evidenzen benötigt.

Zusätzlich werden durch die Ontologien Datenmodelle entwickelt, die für den domänenspezifischen Informationsbedarf der DE4A-Piloten bereitstehen. Sie wurden als maximaler Satz von Konzepten und Attributen definiert, sodass die spezifischen notwendigen Datenmodelle für die einzelnen Pilotanwendungen daraus resultieren können.

Die Ergebnisse aus der Trust-Forschung in DE4A sollen ein allgemeines Bild eines gültigen Trust-Framework für das Projekt erstellen. Die spezifische Forschung im Trust-Bereich in DE4A fokussiert sich auf Vorgaben aus verschiedenen regulatorischen Rahmenbedingungen, wie eIDAS oder SDGR (und anderen).¹³ Nationale Konzepte zu digitalen Services und Infrastrukturen und deren Interoperabilität werden zudem erhoben und diese Ergebnisse zeigten, dass sich hier eine heterogene Landschaft in Bezug auf Trust-Modelle ergibt. In Bezug auf eIDAS ergibt sich eine weitgehende Überlappung zwischen nationalen Strategien und auch den entsprechenden Abbildungen auf europäischer Ebene, was den Vorteil mit sich bringt, dass ein gutes europäisches Zusammenspiel und ein hoher Umsetzungsgrad von eIDAS für die Umsetzung bei des OOTS von großer Bedeutung ist (...und zwar sowohl in E-ID wie auch bei den Trust-Services).

Besondere Betrachtung erfahren auch die Trust-Modelle der CEF Building Blocks. Diesbezüglich wurden vor allem CEF eID und CEF eDelivery, beides Anwendungen mit delegierten Trust-Modellen, das auch für DE4A relevant ist, analysiert, da beide über Knoten verfügen, die als vertrauenswürdige Proxys in den Mitgliedsstaaten dienen; wobei die nationalen beteiligten Systeme mit diesen als Trust-Systemen dienenden zentralen Endpunkten die Daten anfordern oder bereitstellen.¹⁴ Für die Herstellung von Trust in CEF eDelivery ist es notwendig, dass die digitalen Zertifikate als Vertrauensanker zur Schaffung der erforderliche Vertraulichkeit, Integrität und Nichtabstreitbarkeit der Daten ermöglicht systemübergreifend ausgetauscht werden können. Aus mehreren möglichen Umsetzungsvarianten wurde nach der Untersuchung die Einführung des Vertrauensmodells die Dedicated Domain PKI für DE4A vorgeschlagen.¹⁵

Abschließend wird im Bereich der Trust-Forschung die Blockchain-unterstützte Lösung analysiert, um die Einsatzmöglichkeit dieses Technologieansatzes in Bezug auf Trust zu validieren. Blockchain wird für die Implementierung des Patterns Verifiable Credentials benutzt. In diesem Bezug wird ein generischer Blockchain-Ansatz präferiert, um eine breite Nutzung zu gewährleisten und auch, um für die weitere Verwendbarkeit zu erleichtern.

DE4A setzt die technischen Entwicklungen, inkl. der notwendigen Adaptionen der E-Government-Services auf nationaler Ebene, in drei Pilotbereiche um. Die drei Pilotbereiche weisen jeweils zwei Iterationen auf, die zweite Iteration mit einer funktionalen Erweiterung der Pilotanwendungen, des pilotspezifischen Haupt-Pattern oder die zusätzliche Integration eines oder weiterer Pattern.

Die drei Pilotbereiche sind:

Doing Business Abroad: Der Pilot zielt darauf ab, den Verwaltungsaufwand für den Beginn einer Geschäftstätigkeit eines Unternehmens in einem anderen europäischen Mitgliedstaat zu verringern. Zuerst wird ein Vertreter eines Unternehmens über eIDAS identifiziert und das Vertretungsrecht eruiert. Mittels OOP werden additive Daten über das Unternehmen grenzüberschreitend ausgetauscht, was die Zeit für die Registrierung in einem E-Government-Portal (oder Anwendung) im jeweiligen verkürzt. Der gesamte Prozess soll vollständig online demonstriert werden.

Studying Abroad: Die Mobilität bei der Ausbildung ist in Europa sehr wichtig und in mehreren Programmen, unter anderem ERASMUS, formalisiert. Dieser Pilotbereich unterstützt Benutzer*innen durch die digitale Beschaffung von Studienunterlagen nach dem OOP. Drei Anwendungsfälle werden zeigen, wie der Verwaltungsaufwand durch die Wiederverwendung von Daten/Evidenzen aus vertrauenswürdigen Quellen sowie durch die Erhöhung des Sicherheitsniveaus für grenzüberschreitende Dienste und die verstärkte Verwendung elektronischer Identitäten verringert werden kann.

Die drei Anwendungsfälle sind:¹⁶

• Zulassung zu höherer Bildung an Universitäten
• Bewerbung für Studienzuschüssen
• Anerkennung von Diplomen/Zeugnissen

Moving Abroad: Dieser Pilotbereich zielt darauf ab, EU-Bürger zu unterstützen, die ihren Wohnsitz von einem Mitgliedstaat in einen anderen verlegen, indem ein digitalisierter Prozess für den Austausch von Daten/Evidenzen nach dem OOP geschaffen wird, der für diesen Wohnsitzwechsel und andere grenzüberschreitende Online-Verfahren auf der Grundlage von Personenstandsurkunden erforderlich ist. Drei Anwendungsfälle zeigen, wie Daten/Evidenzen vom Mitglied angefordert und geliefert werden können.

Die drei Anwendungsfälle, die das Pilotprojekt adressiert, sind:

• Adressänderung
• Anfrage zu Geburts-, Heirats- und Sterbe-Urkunden
• Anfrage zu Pensionsinformationen und/oder Pensionsanspruch

Die österreichischen Partner sind im Pilotbereich Doing Business Abroad engagiert. Die österreichische Ausformung des Piloten ist die Registrierung eines ausländischen Unternehmens (aus den Niederlanden, Rumänien und Schweden) im USP. Gemäß dem zugrundeliegenden Pattern findet die vollständigen Benutzer-Interaktionen im OOP-Prozess – Verfahren, Explizit Request, Preview – auf der Seite des DR statt. Die Komplexität liegt nicht nur bei der Durchführung der OOP-Prozesse und der nationalen digitalen Verfahrensprozesse, sondern zuallervorderst bei der Integration einer Vertretungsregelung (Person → Unternehmen) im Identifikationsprozess über eIDAS.¹⁷ Diese Erweiterung wird in die jeweiligen nationalen eIDAS-Anwendungen pilothaft integriert und demonstriert. Für die zweite Iteration im DBA-Piloten ist geplant, diese Funktion im österreichischen Piloten durch die Integration der SEMPER-Funktionalitäten¹⁸ – also eine inhaltliche Verfeinerung der Vertretungsrechte („fine-grained“ electronic powers of representation and mandates) zu erweitern.

In weiterer Folge finden die Eintragungen in die österreichischen Stammzahlenregister ERnP (Ergänzungsregister für natürliche Personen) und ERsB (Ergänzungsregister für sonstige Betroffene, für nicht-natürliche Personen) auf Basis der eIDAS-Identifikation statt.¹⁹

Durch den integrierten OOP-Prozess werden zusätzliche Daten (Attribute) des Unternehmens aus dem jeweiligen Mitgliedsstaat abgefragt und übermittelt.²⁰ Diese additiven Daten werden zu den eIDAS-Daten (Minimal Data Sets für die natürliche und die nicht-natürliche Person) beim Eintrag in das Stammzahlenregister hinzugefügt. Abschließend findet die Registrierung im USP statt, worauf auf die Identifikationsmerkmale (IDs) aus den Stammzahlenregistern zurückgegriffen wird.²¹

Die Herausforderungen im österreichischen Piloten liegen in der Zusammenführung von mehreren etablierten mit neuen E-Government-Prozessen sowie in deren spezifischen Ausprägung, einerseits als nationale aber auch als grenzüberschreitende europäische Prozesse.²² Der Registrierungsprozess für die Nutzung des USP finden bis dato unter Einbezug von manuellen Prozessen statt; Kopien von Dokumenten zu Unternehmen, Person sowie deren Vertretungsbefugnissen werden per E-Mail gesandt und fachlich gewürdigt. Diesbezüglich ist eine Online-Identifikation/Authentisierung bis dato nicht vorgesehen. Hier setzt die erste Neuerung durch den DE4A-Piloten an, und zwar in der eIDAS-Identifikation inklusive Eruierung der Vertretungsbefugnis der handelnden natürlichen Person.²³ Im zweiten Schritt werden die Daten zu natürlicher und nicht-natürlicher Person automatisiert im ERsB und ERnP eingetragen (eIDAS Minimal Data Sets). Die Registrierung des Unternehmens und der vertretenden Person findet im USP statt und es wird der/die Benutzer*in in den Administrationsbereich des USP weitergeleitet. Für die Umsetzung des OOP werden in einem weiteren Schritt additive Daten zum Unternehmen, gemäß Evidenzmodell des Piloten, über die Once-Only-Infrastruktur des DE4A-Projekts angefragt und bezogen; mit diesen werden die bestehenden Daten zum Unternehmen im ERsB angereichert. Dabei werden auch die Mechanismen des Explicit Request und Preview gemäß SDGR umgesetzt und pilotiert.

Abbildung 1: Überblick über österreichischen Pilotprozess in DE4A

Die Nutzung von Wissen und technischen Entwicklungen aus EU-Projekten hat sich bereits als wichtiges Element für E-Government-Umsetzungen herausgestellt, das hat die Erfahrung bereits mehrfach gezeigt; das gilt umso mehr, wenn die Vorhaben ein verteiltes technisches System über Europa darstellen (OOTS des SDG) und zudem noch auf der Verpflichtung von rechtlichen Vorgaben (der SDGR) basieren. Im spezifischen Fall kann bereits auf eine bestehende Projektkette referenziert werden, eben von TOOP zu DE4A. Die thematische Beschäftigung kann sogar als eine direkte Linie von PEPPOL und FutureTrust zu TOOP und DE4A gezogen werden, daher ist das Erfahrungswissen in diesen verwandten Themenbereichen bereits seit über 13 Jahren aufgebaut worden.²⁴

Nicht nur das Projekt DE4A profitiert von den Entwicklungen aus Vorentwicklungen, das österreichische E-Government selbst hat und kann von den Ergebnissen aus mehreren Perspektiven profitieren: Strategiebildung, Standardisierung, Software-Spezifikation und -entwicklung, praktische pilothafte Anwendung und verbundener Know-how-Aufbau, wie aber auch schon allein durch die Vernetzung der handelnden Expert*innen.

Aus den forschungsorientierten Ergebnissen, wie aus den Erkenntnissen aus der Pilotanwendung können aus DE4A folgende Vorteile für die Partner, und damit für Österreich, erwartet werden:

• In DE4A sind die Piloten sehr realitätsnah angelegt, sie folgen stringenten Geschäftsprozessen in Bezug auf Interoperabilität (Pattern), diese können als Blueprint für weitere nationalen Interoperabilitätsmaßnahmen (auch mit Europa-Konnex) genutzt werden;
• die technisch-architekturellen Konzepte und Entwicklungen in DE4A bringen konkrete Funktionen/Komponenten/Systeme hervor, die für die folgende Umsetzung des SDG wichtige Betrachtungselemente darstellen können;
• die Forschungsergebnisse aus Semantics und Trust werden dem Know-how-Aufbau in diesen Bereichen unterstützen, fließen aber bereits in die technischen Entwicklungen für die Piloten ein, sind also nicht nur als Konzepte, sondern auch als Realumsetzung zu erachten;
• das Know-how aus den spezifischen Inhalten brachten das Wissen zu den laufenden SDG-Tätigkeiten, vor allem in Hinblick auf die Durchführungsrechtsakte zu Artikel 14 der SDGR und dem darin enthaltenen OOP;
• der Austausch mit Expert*innen rund um die Architekturentwicklung, Komponentenentwicklung und Pilot-Umsetzung hat bereits einen positiven Einfluss auf die technische (und organisatorische) Umsetzung des OOP für SDG in Österreich gezeigt, sowie eine tiefere Verankerung der Themen in das österreichische E-Government-Spektrum ergeben.

DE4A: Deliverable 2.2 – Initial DE4A Trust Management Models and Blockchain Support Framework, https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/f739c2_2a098af5a8de44838de049ee83641285.pdf

DE4A: Deliverable 2.4 – Project Start Architecture (PSA), first iteration, https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/f739c2_fa17b6508b4744bf9872b59faa70cca3.pdf

DE4A: Deliverable 3.3 – Semantic Framework – Initial version, https://b0b3923b-028b-4cc4-aa23-7b874a2ae593.filesusr.com/ugd/f739c2_bbefa1524d5f4dc9917b049cee1c28f6.pdf

DE4A Website: www.de4a.eu

EU CEF Building Blocks: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/What+is+a+Building+Block

EU Projekte, Instrument RIA: https://ec.europa.eu/research/participants/data/ref/h2020/other/wp/2018-2020/annexes/h2020-wp1820-annex-d-ria_en.pdf

FutureTrust in CORDIS: https://cordis.europa.eu/project/id/700542/de

Krimmer, Robert/Prentza Andriana/Mamrot Szymon: The Once-Only Principle: The TOOP Project, (2021)

Layne Karen/Lee jungwoo: Developing fully functional E-government: A four stage model (2001): https://www.researchgate.net/publication/223498089_Developing_Fully_Functional_E-Government_A_Four_Stage_Model oder https://www.sciencedirect.com/science/article/abs/pii/S0740624X01000661?via%3Dihub

Once Only Principle: https://de.wikipedia.org/wiki/Once-Only-Prinzip#:~:text=Ziel%20des%20Once%2DOnly%2DPrinzips,nur%20noch%20einmal%20mitteilen%20m%C3%BCssen.

Peppol in Wikipedia: https://de.wikipedia.org/wiki/PEPPOL

Piswanger, Carl-Markus/Helger, Philip/John Klaus: A Shortcut on „The Once Only Principle Project“ (TOOP), (2019), in https://jusletter-it.weblaw.ch/issues/2019/IRIS/a-shortcut-on---the-_d0b9171939.html

Semper Projekt: https://graz.pure.elsevier.com/en/projects/eu-semper-crossborder-semantic-interoperability-of-powers-and-man

Semper Projekt: https://ec.europa.eu/inea/en/connecting-europe-facility/cef-telecom/2018-eu-ia-0032

Single Digital Gateway Verordnung: https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX: 32018R1724&from=EN

TOOP, Exchange Data Model: http://wiki.ds.unipi.gr/display/TOOP/TOOP+Exchange+Data+Model

TOOP, Reference Architecture: http://wiki.ds.unipi.gr/display/TOOPRA

TOOP, Website: www.toop.eu

USP: https://www.usp.gv.at