Umsetzung vertrauenswürdiges OGD

Transkript

1 Dokumentation Umsetzung vertrauenswürdiges Version 1.0, Klaus Stranacher Zusammenfassung: Open Government Data () gewinnt immer mehr an Bedeutung sowohl national durch die Plattform data.gv.at als auch im EUweiten Kontext durch die aktualisierte PSI-Richtlinie. Fragen der Integrität und Authentizität der veröffentlichten Daten wurde bisher ausgeklammert. Ein Konzept zur Erhöhung der Vertrauenswürdigkeit der Daten wurde im Projekt OpenData und elektronische Dokumente vorgestellt und nutzt elektronische Signaturen als Mittel zum Zweck. Darauf basierend analysiert und untersuchte das Projekt Analyse Signaturverfahren für mögliche Signaturverfahren für -Datenformate. Das vorliegende Dokument fasst nun die reale Umsetzung eines vertrauenswürdigen sowohl server- als auch clientseitig basierenden auf den Ergebnissen der Vorgänger-Projekte zusammen. E-Government Innovationszentrum Inffeldgasse 16/a, A-8010 Graz Tel Fax Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

2 Inhaltsverzeichnis 1 Einleitung Vertrauenswürdiges Einleitung Grundprinzip Signaturfähigkeit Datenformate Anforderungen Modularität und Anpassungsfähigkeit Einfache Integration Interoperabilität Automatische Verarbeitung Sicherheit und Datenschutz Architektur Einleitung Serverseitige Architektur Clientseitige Architektur Implementierung Einleitung Serverseitige Implementierung Clientseitige Implementierung Zusammenfassung Abbildungsverzeichnis Abbildung 2.1 Grundprinzip vertrauenswürdiges [Stra12] Abbildung 4.1 Serverseitige Architektur Abbildung 4.2 Clientseitige Architektur Abbildung 5.1 Clientseitige Implementierung Abbildung 5.2 Screenshot I Android-App Abbildung 5.3 Screenshot II Android-App Einleitung 2

3 1 Einleitung Open Government Data () ist zurzeit eines der großen Themen im Bereich des E- Government. Mit der aktualisierten PSI-Richtlinie wurde auch auf EU-Ebene ein Rahmenwerk geschaffen um zukünftige -Entwicklungen auf eine gemeinsame Basis zu stellen. Wie bereits im Vorgänger-Projekt OpenData und elektronische Dokumente [Stra12] dargestellt wurden Integrität und Authentizität der veröffentlichten Daten nur sehr rudimentär behandelt. Darum wurde in diesem Projekt ein Konzept für ein vertrauenswürdiges vorgestellt. Zum Einsatz kommen hierbei elektronische Signaturen. Im Projekt Analyse Signaturverfahren für [Stra13b] wurden in weiterer Folge Datenformate und deren Signaturfähigkeit untersucht. Des Weiteren wurde im Projekt Analyse PSI-Richtlinie und Metadaten Standards [Stra13a] das vorhandene Konzept auf die Anwendbarkeit auf die Anwendungsfälle der (neuen) PSI-Richtlinie und auf () Metadaten erweitert. Das vorliegende Dokument stellt nun das letzte Projekt dieser Projektreihe dar und zeigt die konkrete prototypische Umsetzung eines vertrauenswürdigen. Der Rest dieses Dokuments ist daher wie folgt aufgebaut. Abschnitt 2 befasst sich mit den Ergebnissen der Vorgänger-Projekte und fasst das Konzept für ein vertrauenswürdiges und Signaturverfahren für zusammen. Der folgende Abschnitt 3 identifiziert konkrete Anforderungen für eine reale Umsetzung eines vertrauenswürdigen. Basierend auf diesen Anforderungen befasst sich der Abschnitt 4 mit der server- und clientseitigen Architektur. Abschnitt 5 präsentiert anschließend die prototypische client- und serverseitige Umsetzung. Der Abschnitt 6 fasst die Ergebnisse abschließend zusammen. Einleitung 3

4 2 Vertrauenswürdiges 2.1 Einleitung Für die Bereitstellung von besteht eine Reihe von Anforderungen, wie beispielsweise Vollständigkeit, leichter Zugang oder Primärquelle. Weitere Details zu diesen Anforderungen finden sich in der Projektdokumentation Open Data und elektronische Dokumente [Stra12], den Open Data Principles der Open Government Working Group [OGW07] bzw. in den Rahmenbedingungen für Open Government Data Plattformen der Projektgruppe Cooperation Open Government Data Österreich [AT]. In sämtlichen Anforderungen für befinden sich jedoch keinerlei Informationen hinsichtlich der Sicherheit und Vertrauenswürdigkeit der bereitgestellten Daten. Auch das Informationsweiterverwendungsgesetz [IWG05] und die PSI-Richtlinie [Eur03, Euro13] befassen sich mit dieser Thematik nicht. Hierzu wurden im Projekt Open Data und elektronische Dokumente [Stra12] zusätzliche Anforderungen definiert und ein vertrauenswürdiges zu ermöglichen. Innerhalb dieses Projekts wurde zusätzlich auch ein Konzept präsentiert um authentisch und integritätsgesichert zur Verfügung stellen zu können. Dieses Konzept wird im folgenden Abschnitt 2.2 kurz erläutert. Abschnitt 2.3 fasst abschließend noch die Ergebnisse des Projekts Analyse Signaturverfahren für [Stra13b] zusammen. 2.2 Grundprinzip Das Grundprinzip für ein vertrauenswürdiges beruht auf der Verwendung von elektronischen Signaturen. Abbildung 2.1 veranschaulicht dieses Grundprinzip. Dabei befinden sich die zu veröffentlichenden Daten in der Domäne der Bereitstellerin bzw. des Bereitstellers. Diesen Daten werden nun, vor der Veröffentlichung, von der Bereitstellerin bzw. dem Bereitsteller mit dem privaten Signaturschlüssel der Bereitstellerin bzw. des Bereitstellers signiert. Anschließend werden die signierten Daten an geeigneter Stelle publiziert und stehen als vertrauenswürdiges zum Download zur Verfügung. Die Bezieherin bzw. der Bezieher kann nun die Daten inkl. der Signatur downloaden. Die Signatur der Daten kann nun von der Bezieherin bzw. vom Bezieher überprüft werden. Dies kann mittels einer Signaturprüfung in der eigenen Domäne oder auch über ein externes Signaturprüfservice erfolgen. Nach einer erfolgreichen Signaturprüfung kann die Bezieherin bzw. der Bezieher auf die Vertrauenswürdigkeit der Daten vertrauen. Vertrauenswürdiges 4

5 Durch die Verwendung einer elektronischen Signatur durch die Bereitstellerin bzw. den Bereitsteller bieten sich folgenden Vorteile: Integrität der Daten: Durch die Sicherstellung der Integrität der Daten ist gewährleistet, dass nachträgliche Änderungen der signierten Daten erkannt werden können. Davon profitieren sowohl Bezieherinnen und Bezieher als auch Bereitstellerinnen und Bereitsteller. Einerseits können sich Bezieherinnen und Bezieher darauf verlassen richtige Daten erhalten zu haben, andererseits können Bezieherinnen und Bezieher nicht behaupten falsche Daten erhalten zu haben (Vorteil für Bereitstellerinnen und Bereitsteller). Authentizität der Bereitstellerin bzw. Bereitstellers: Die Bezieherin bzw. der Bezieher kann die Identität der Bereitstellerin bzw. des Bereitstellers feststellen. Beliebige (nicht vertrauenswürdige) Domäne SIGNATUR PRÜFUNG Domäne Open Data Bereitsteller/in Domäne Open Data Bezieher/in Lorem ipsum Lorem dolor ipsum sit amet, Lorem dolor ipsum consetetur sit amet, dolor sadipscing consetetur sit amet, elitr, sadipscing consetetur sed diam elitr, sadipscing nonumy sed diam elitr, eirmod nonumy sed diam tempor eirmod invidunt nonumy tempor eirmod invidunt tempor invidunt SIGNATUR ERSTELLUNG Lorem ipsum Lorem dolor ipsum sit amet, Lorem dolor ipsum consetetur sit amet, dolor sadipscing consetetur sit amet, elitr, sadipscing consetetur sed diam elitr, sadipscing nonumy sed diam elitr, eirmod nonumy sed diam tempor eirmod invidunt nonumy tempor eirmod invidunt tempor invidunt Original Datenquelle Vertrauenswürdiges Open Data Abbildung 2.1 Grundprinzip vertrauenswürdiges [Stra12]. Vertrauenswürdiges 5

6 2.3 Signaturfähigkeit Datenformate Im Bereich von werden unterschiedlichste Datenformate eingesetzt. Neben den verschiedenen Eigenschaften und Anwendungsgebieten wurde im Projekt Analyse Signaturverfahren für [Stra13b] verschiedene, weit verbreitete, Datenformat auf ihre Signaturfähigkeit untersucht. Tabelle 1 fasst die Ergebnisse der Analyse zusammen. Diese Tabelle zeigt, dass für prinzipiell jedes untersuchte Datenformat ein Signaturformat entsprechend der EU Kommissionsentscheidung 2011/130EU [Euro11] gefunden werden konnte. Hierbei hat sich herausgestellt, dass speziell XAdES- und CAdES-Signaturen je nach Datenformat die beste Wahl sind. PAdES-Signaturen eignen sich dabei nur für PDF- Dokumente, die trotz schlechter automatischer Weitverarbeitungsmöglichkeiten im -Bereich weit verbreitet sind. Tabelle 1 Signaturfähigkeit [Stra13b]. Format Kurzbeschreibung CAdES XAdES PAdES CSV Text basiertes Format mit der Möglichkeit x einer einfach strukturierten Angabe der Daten über Trennzeichen. XML Text basiertes Format mit der Möglichkeit x x sehr komplexe Strukturen über XML- Elemente abzubilden. KML/KMZ XML basiertes Geodatenformat speziell für Google Earth und Google-Maps 1 x GML XML basiertes Geodatenformat zur x x Beschreibung von Objekten und deren Eigenschaften SHP Geodatenformat speziellen für den Einsatz in GIS-Anwendungen und aus mehreren Dateien bestehend x x SVG XML basiertes Format für skalierbare 2 x Vektorgrafiken PDF Datei im weltweit etablierten PDF-Format x x ZIP Containerformat in dem beliebige Dateien komprimiert gespeichert werden können x x 1 Prinzipiell eignet sich XAdES für KML besser. Für die ZIP-komprimierte Variante (KMZ) kommt aber auch CAdES in Frage. 2 Prinzipiell eignet sich XAdES für SVG besser. Für die ZIP-komprimierte Variante kommt aber auch CAdES in Frage. Vertrauenswürdiges 6

7 3 Anforderungen Dieser Abschnitt befasst sich mit konkreten Anforderungen in Bezug auf eine reale Umsetzung eines vertrauenswürdigen. Im Projektbericht zu OpenData und elektronische Dokumente [Stra12] wurde hierzu nur das grundsätzlichen Konzept vorgestellt. Konkrete Anforderungen wurden jedoch noch keine festgelegt. Dies wird nun nachgeholt. Folgende konkreten Anforderungen konnten identifiziert werden und müssen sowohl von der generellen Architektur als auch der Implementierung erfüllt werden: Modularität und Anpassungsfähigkeit Einfache Integration Interoperabilität Automatische Verarbeitung Sicherheit und Datenschutz Die folgenden Unterabschnitte befassen sich detaillierte mit diesen Anforderungen. 3.1 Modularität und Anpassungsfähigkeit Die IT-Infrastruktur ist ständigen Veränderungen unterworfen. Diese müssen sowohl von der Architektur als auch der Implementierung so weit wie möglich berücksichtigt werden. Aus diesem Grund müssen Architektur und Implementierung einem modularen und anpassungsfähigen Ansatz verfolgen. Zusätzliche Module, im Speziellen Module zur Unterstützung weiterer Signatur- und Datenformate, sollen einfach eingebunden werden können. 3.2 Einfache Integration In den meisten Fällen existiert bei den zuständigen Stellen eine entsprechende Infrastruktur zur Veröffentlichung von. Um weitere Kosten zu minimieren und auch bereits investierte Kosten bestmöglich auszunutzen müssen die Architektur und die Implementierung einfach in die bestehende Infrastruktur eingebunden werden können. Eine einfache Integration, kombiniert mit einer ebenfalls einfachen und intuitiven Konfiguration, ermöglicht ein schnelles Aufgreifen der Lösung seitens der Stellen, die veröffentlichen. 3.3 Interoperabilität Interoperable Dienste sind einer der Hauptziele der EU Digitalen Agenda für Europa speziell im grenzüberschreitenden Kontext. Für unseren Anwendungsfall betrifft dies vor allem die Signatur- und Datenformate. Aus diesem Grund müssen die Architektur und die Implementierung den Vorgaben des Europäischen Interoperabilitäts- Anforderungen 7

8 Framework (EIF) 3 folgen. Insbesondere müssen aktuelle Entscheidungen im Bereich Signatur- und Datenformate berücksichtigt werden. 3.4 Automatische Verarbeitung Architektur und Umsetzungen müssen so designt und entwickelt werden, dass sie einen automatische Weiterverarbeitung der Daten ermöglichen. Jede manuelle Interaktion soll eliminiert werden. 3.5 Sicherheit und Datenschutz Aktuelle Sicherheits-Richtlinien und Datenschutz-Regulierungen müssen entsprechend und soweit zutreffend von der Architektur und der Implementierung beachtet werden. 3 Anforderungen 8

9 4 Architektur 4.1 Einleitung Die Architektur für ein vertrauenswürdiges umfasst sowohl eine Server- als auch einen Clientseite. Die Serverseite befindet sich in der Domäne der Bereitstellerin bzw. der Bereitstellers und ist verantwortlich für das Aufbringen der elektronischen Signatur auf die zu veröffentlichenden Daten. Clientseitig, d.h. von der Bezieherin bzw. dem Bezieher, werden diese signierten Daten konsumiert. Die folgenden Unterabschnitte befassen sich nun detaillierte mit der server- und clientseitigen Architektur. 4.2 Serverseitige Architektur Abbildung 4.1 veranschaulicht die serverseitige Architektur und zeigt wie diese in eine existierende Infrastruktur integriert werden kann. Die existierende Infrastruktur wurde hierzu generalisiert und besteht aus folgenden Komponenten (inklusive dem ursprünglich Prozessfluss): Datenquelle: Repräsentiert die originale Datenquelle, die als Basis für die Erzeugung von herangezogen wird. Vorbereitung: Diese Komponente generiert die Daten aus der originalen Datenquelle und übermittelt diese an die Komponente Veröffentlichung. Veröffentlichung: Die generierten Daten werden von dieser Komponenten in geeigneter Weise veröffentlicht. Diese existierende Architektur wurde nun erweitert um ein vertrauenswürdiges zu ermöglichen. Diese erweiterte Architektur wurde modulmäßig aufgebaut und besteht aus folgenden Komponenten (inklusive deren Interaktion und dem Prozessfluss): Konfiguration: Diese Komponente beinhaltet die gesamte Konfiguration und stellt entsprechende Schnittstellen zur Abfrage der Konfiguration zur Verfügung. Dabei enthält die Konfiguration zumindest folgende Daten: (1) die Mapping der Datenformat auf das entsprechende Signaturformat (siehe Abschnitt 2.3) und (2) die privaten Schlüssel, die zur Erzeugung der Signatur benötigt werden. Diese Schlüssel können dabei Softwareschlüssel (als Datei hinterlegt) oder auch Hardwareschlüssel (über ein Hardware Security Modul eingebunden) sein. Datenformat Erkennung: Aufgrund der individuelle Charakteristik der verschiedenen Datenformate, versucht diese Komponente das Datenformat der einlangenden Daten herauszufinden. Die Daten Architektur 9

10 selbst und das erkannte Datenformat werden in weiterer Folge an den Datenformat Broker übermittelt. Datenformat Broker: Basierend auf dem konfigurierten Format-Mapping wählt der Broker das entsprechende Signaturformat für die eingelangten Daten aus und leitet die Daten an den Connector weiter. Connector: Der Connector stellt eine gemeinsame Schnittstelle zwischen Datenformat Broker und den Signatoren für die verschiedenen Signaturformate zur Verfügung. Signatoren: Basierend auf der EU Kommissionsentscheidung 2011/130EU und dem Ergebnis präsentiert in Abschnitt 2.3 sind derzeit drei verschiedene Signatoren definiert (PAdES-, CAdES- und XAdES-Signator). Jeder Signator bekommt über die Konfiguration den entsprechenden privaten Schlüssel und signiert damit die erhaltenen Daten entsprechend der jeweiligen Spezifikation. Durch die abstrahierte gemeinsame Schnittstelle können an dieser Stelle auch weitere zusätzliche Signatoren prinzipiellen hinzugefügt werden. Konfiguration Format Mapping Private Schlüssel XML XAdES PDF PAdES SHP CAdES PAdES Signator CAdES Signator Connector Common Interface XAdES Signator Daten Vorbereitung Datenformat Erkennung Format Datenformat Broker Veröffentlichung Datenquelle Existierende Infrastruktur 4.3 Clientseitige Architektur Abbildung 4.1 Serverseitige Architektur. Abbildung 4.2 illustriert die clientseitige Architektur. Die Architektur ist allgemein gehalten, das sie als Smartphone-App, als Webapplikation oder jeden anderen Applikationstyp angewendet werden kann. Die involvierten Komponenten und der Prozessfluss sind: Daten Retrieval: Diese Komponente bezieht die signierten Daten von der veröffentlichten Quelle und leitet diese an den Signaturprüfungs-Broker weiter. Architektur 10

11 Signaturprüfungs-Broker: Dieser Broker startet den Signaturprüfprozess und evaluiert dann das erhaltene Prüfergebnis. Abhängig von der konkreten Implementierung kann die Signaturprüfung über eine interne (selbst implementierte) Signaturprüfung erfolgen oder es wird ein externe Signaturprüfdienst genutzt. Nach der Evaluierung des Prüfergebnisses erfolgt jedenfalls die Weiterleitung an die App Engine. Interne Signaturprüfung und externer Signaturprüfdienst: Diese Komponenten übernehmen die eigentliche Signaturprüfung. Entweder kann eine eigene interne Signaturprüfkomponente implementiert werden oder man nutzt einen externen Signaturprüfdienst. Externe Prüfdienste sind im Allgemeinen vorteilhaft da sie mehrere Signaturformate unterstützen und zumeist auch eine Webschnittstelle zur Verfügung stellen, die weit leichter zu nutzen ist als selbst eine komplexe Signaturprüfung zu implementieren. Speziell Applikationen, die wenig Ressourcen zur Verfügung haben, wie Smartphone-Apps, können davon profitieren. App Engine: Die App Engine repräsentiert die eigentliche Applikation und dient der Visualisierung der erhaltenen Daten, wenn die Signatur erfolgreich geprüft werden konnte. Externer Signaturprüfdienst Prüfresultat Daten Retrieval Signatur Verifikation Broker Prüfresultat Interne Signaturprüfung App Engine Abbildung 4.2 Clientseitige Architektur. Architektur 11

12 5 Implementierung 5.1 Einleitung Zur Evaluierung der vorgeschlagenen Architekturen wurde eine prototypische Implementierung der Server- und Client-Seite vorgenommen. Die folgenden Unterabschnitte befassen sich mit diesen beiden Implementierungen. 5.2 Serverseitige Implementierung Für die serverseitige Komponente wurde ein prototypischer Dienst implementiert, dem Daten übergeben werden und die signierten Daten zurückliefert. Abbildung 5.1 zeigt diese konkrete serverseitige Umsetzung. Die Datenformat Erkennung beruht dabei auf der Format-Erkennung von [Zeff11]. Für die Erstellung der Signatur dient das Open-Source Modul MOA-SS 4 zur Erstellung von serverseitigen CAdES bzw. XAdES Signaturen. Es werden daher sämtliche Datenformate unterstützt, die zumindest auf eines der beiden Formate mappen. Nach Erhalt der signierten Daten können diese entsprechende veröffentlicht werden. Diese prototypische Umsetzung steht dabei als Webapplikation als auch als Command-Line Version als Anhang zu diesem Dokument zur Verfügung. Format Mapping XML XAdES PDF PAdES SHP CAdES Konfiguration MOA-SS Key Identifiers SignatureKeyID MOA-SS Common Interface Signed Datenformat Erkennung Format Datenformat Broker Veröffentlichung Quelle: data.gv.at Abbildung 5.1 Clientseitige Implementierung. 4 Implementierung 12

13 5.3 Clientseitige Implementierung Auf Client-Seite wurde eine prototypische Android App implementiert, die einen konkreten signierten Datensatz einliest, die Signaturprüfung vornimmt und die Daten anschließend darstellt. Als Datensatz wurde dabei NEXTBIKE NÖ Fahrradverleihsystem 5 von der Plattform data.gv.at herangezogen. Diese XMLbasierten Daten repräsentierten die Verfügbarkeit von Fahrrädern bei verschiedenen Verleihstationen im Bundesland Niederösterreich. Der gesamte Datensatz wurde mittels der serverseitigen Implementierung signiert und auf einem Webserver veröffentlicht. Diese signierten Daten werden von der Android App eingelesen. Anschließend erfolgt die Signaturprüfung, wobei diese aufgrund der limitierten Ressourcen über einen externen Signaturprüfdienst erfolgt. Da die entsprechende Web-Service Schnittstelle vom Signaturprüfservice der RTR unter noch nicht zur Verfügung steht, wurde stattdessen das entsprechende Service von genutzt. Nach einer erfolgreichen Signaturprüfung (siehe Meldung Valid in Abbildung 5.2) werden die Daten im Listenformat angezeigt. Bei Auswahl einer Verleihstation (siehe Abbildung 5.3) gibt es noch die Möglichkeit sich diese Station auf Google Maps anzeigen zu lassen. Anmerkung: Die Android-App wurde im Zuge der Lehrveranstaltung AK-IT Sicherheit 1 (E-Government) von Sandra Fruhmann und Patrick Koch (betreut durch Klaus Stranacher) implementiert. Die Android-App steht im Anhang zu diesem Dokument zur Verfügung. Abbildung 5.2 Screenshot I Android-App. 5 Implementierung 13

14 Abbildung 5.3 Screenshot II Android-App. Implementierung 14

15 6 Zusammenfassung Das vorliegende Dokument befasst sich mit der finalen Umsetzung eines vertrauenswürdigen basierend auf elektronischen Signaturen. Basierend auf Vorgängerprojekten wurden zuerst konkrete Anforderungen für eine reale Umsetzung definiert. Diese Anforderungen waren anschließend Ausgangspunkt für die Entwicklung allgemeiner Architekturen für die server- und clientseitige Umsetzung. Die abschließenden prototypischen Implementierungen demonstrieren die Praktikabilität und Umsetzbarkeit eines vertrauenswürdigen. Dabei können über die serverseitige Applikation, mittels des Moduls MOA-SS, entsprechend signierte Daten erzeugt werden. Clientseitig wurde eine Android-App implementiert, die an einem konkreten Beispiel die Umsetzbarkeit zeigt. Zusammenfassung 15

16 Dokumentenhistorie Version Datum Autor(en) Anmerkung K.Stranacher Erstversion mit Abschnitt 2 Grundprinzip und Abschnitt 3 Anforderungen K.Stranacher Abschnitt K.Stranacher Abschnitt K.Stranacher Finalisierung, Endversion Zusammenfassung 16

17 Referenzen [Euro00] [Euro03] [Euro10] [Euro11] [Euro13] European Union, Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures, Official Journal L 13, pp European Union (2003) Directive 2003/98/EC of the European Parliament and the Council of 17 November 2003 on the re-use of public sector information. European Commission, Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions A Digital Agenda for Europe, COM/2010/0245, European Commission Decision, Establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market, notified under document C(2011) 1081, 2011/130/EU, European Union (2013), Directive 2013/37/EU of the European Parliament and of the Council of 26 June 2013 amending Directive 2003/98/EC on the re-use of public sector information. [IWG05] Bundesgesetz über die Weiterverwendung von Informationen öffentlicher Stellen (Informationsweiterverwendungsgesetz IWG), StF: BGBl. I Nr. 135/2005 (NR: GP XXII RV 1026 AB 1150 S BR: AB 7425 S. 727.) [AT] Projektgruppe Cooperation Open Government Data Österreich, Rahmenbedingungen für Open Government Data Plattformen, White Paper, Version 1.1.0, , [OGW07] [Stra12] [Stra13a] [Stra13b] [Zeff11] Open Government Working Group, 8 Principles of Open Government Data, K. Stranacher, EGIZ Projekt-Dokumentation OpenData und elektronische Dokumente, Version 1.0, 14.November 2012 K. Stranacher, EGIZ Projekt-Dokumentation Analyse PSI-Richtlinie und Metadaten Standards, Version 1.0, 4.Dezember 2013 K. Stranacher, EGIZ Projekt-Dokumentation Analyse Signaturverfahren für Open Government Data, Version 1.0, Zefferer et al., Secure and Reliable Online-Verification of Electronic Signatures in the Digital Age, in Proceedings of the IADIS International Conference WWW/INTERNET, 2011, pp Zusammenfassung 17