Bern ein Framework für rechtsverbindlichen Austausch von strukturierten Dokumenten (Formularen)

Transkript

1 Bern ein Framework für rechtsverbindlichen Austausch von strukturierten Dokumenten (Formularen)

2 enda Ausgangssituation im Projekt GovLink Anforderungen an den rechtsverbindlichen Austausch von strukturierten Dokumenten Lösungssuche OSCI (Online Services Computer Interface ) OSCI-Implementierung (Governikus) Zusammenfassung / Ausblick :18; Seite 2

3 Kapitel 1 Ausgangssituation im Projekt GovLink Wie alles begann :18; Seite 3

4 Gemeinsames Bedürfnis nach rechtsverbindlichem Transport sgangssituation Mehrere Anwendungen haben dieselbe Grundanforderung: Sie benötigen einen rechtsverbindlichen Transport von strukturierten Dokumenten. Beispiele: Handelsregister (Anmeldung für Eintrag) Elektronischer Rechtsverkehr (JusLink) :18; Seite 4

5 Gründe für die Entwicklung oder Evaluation eines Standards sgangssituation Verkürzung von Projektzeiten Interoperabilität Investitionsschutz Erreichbarkeit der kritischen Masse :18; Seite 5

6 Auftrag GovLink sgangssituation Entwicklung und Evaluation eines Frameworks für den rechtsverbindlichen, elektronischen Austausch strukturierter Dokumente unter Berücksichtigung folgender Aspekte: Rechtsverbindlichkeit und Sicherheit Schliessen von Prozessketten Eliminierung von Medienbrüchen Verwendung von Industrie-Standards Flexibilität und Ausbaumöglichkeit :18; Seite 6

7 Kapitel 2 Anforderungen an den rechtsverbindlichen Austausch von strukturierten Dokumenten Sicher ist nicht genug! :18; Seite 7

8 Problemstellung anhand eines Beispiels forderungen Einreichung einer Klageschrift bei Gericht Zustellung eines Urteils durch das Gericht Klageschrift Post Klägerin / Anwalt Urteil Klageschrift Urteil Urteil Beklagter / Anwalt Gericht :18; Seite 8

9 Der eingeschriebene Brief von einer Person zur Behörde forderungen Person Behörde Sender Intermediär Empfänger Struktur erzeugen, mit Endempfängerzertifikat verschlüsseln,signieren Meldung Fristeinhaltung Person zu Behörde Quittung Ereignis protokollieren, Quittung erstellen Abholungseinladung Ereignis protokollieren Meldung (Abholung) Zeit :18; Seite 9

10 Der eingeschriebene Brief von einer Behörde zu einer Person forderungen Behörde Person Sender Intermediär Empfänger Struktur erzeugen, mit Endempfängerzertifikat verschlüsseln, signieren Meldung Ereignis protokollieren Meldung steht für Empfänger zur Abholung bereit Quittung (Quittung) 7 Ta ge Quittung erstellen, Ereignis protokollieren Fristbeginn Behörde zu Person Fristbeginn ohne Abholung Abholungseinladung Meldung (Abholung) Zeit :18; Seite 10

11 Die vier klassischen Elemente sicherer Kommunikation forderungen Nichtabstreitbarkeit Authentizität Der Absender kann nachträglich nicht bestreiten, die Nachricht gesendet zu haben Bei den Teilnehmern handelt es sich um die Personen / Organe, für die sie sich ausgeben Integrität Die Nachricht erreicht den Empfänger unverändert Vertraulichkeit Nur der Empfänger ist in der Lage, die Nachricht zu lesen :18; Seite 11

12 Weitere Elemente forderungen Protokollierung (Nachvollziehbarkeit der Übermittlung) Absendezeitpunkt Es wird protokolliert, wann eine Nachricht abgesendet bzw. dem Transportmedium übergeben wurde Zustellungszeitpunkt Es wird protokolliert, wann eine Nachricht abgeholt bzw. zugänglich gemacht wurde Anforderungen an die Struktur von Meldungen Integrierbarkeit Integration in die Arbeitsabläufe und die Systemumgebung der Anwender Automatisierbare Verarbeitung Automatisierbare Verarbeitung der Meldung und ihres Inhalts :18; Seite 12

13 Kapitel Lösungsfindung Architektur 3.2 Beurteilung der klassischen Transport-Technologien 3.3 Analyse von Standardisierungs-Initiativen 3.4 Eigenentwicklung 3.5 OSCI 1.2 Warum nicht einfach ? Welche Technologien und Architekturen kommen für den Austausch strukturierter Dokumente im Justizbereich überhaupt in Frage? :18; Seite 13

14 1 rchitektur Peer To Peer kontra Hub-Architektur Ein unabhängiger Dritter muss den Sendezeitpunkt einer Meldung sicher protokollieren (Fristeinhaltung) Ein unabhängiger Dritter muss den Abholungszeitpunkt einer Meldung sicher protokollieren (Fristbeginn) Anwalt Ein unabhängiger Dritter muss die Zustellungszeitpunkte dem Sender und Empfänger mit signierter Quittung bestätigen können Signaturprüfung und eventuell andere zusätzliche Services sollten zentral angeboten werden können Anwalt Hub Gericht Folglich ist eine Hub-Architektur (Intermediär) notwendig :18; Seite 14

15 2 (Peer to Peer; asynchrones Store And Forward ) assische Technologien Vorteile: Große Verbreitung von Mail-Clients Infrastruktur bereits vorhanden Kostengünstiger Betrieb Einbettung von Zertifikaten möglich Nachteile: Wenig strukturiert Keine verbindliche Zustellung Transaktionszeitpunkte nicht transparent Keine brauchbare Protokollierung Fazit: Ohne signierte Quittierung der Transportzeitpunkte für die rechtsverbindliche Kommunikation ungeeignet :18; Seite 15

16 2 assische Technologien Web-Formularapplikation Vorteile: Server- und Client-Authentifizierung möglich Strukturierung möglich Protokollierung möglich Installation beim Client entfällt (Web-Browser) Nachteile: Clientseitige Signatur und Verschlüsselung der Daten nicht möglich Die Möglichkeiten von Browserformularen sind beschränkt Fazit: Ohne clientseitige Signatur und Verschlüsselung für die rechtsverbindliche Kommunikation ungeeignet :18; Seite 16

17 2 Traditionelles EDI (UN-EDIFact, SWIFT, ) assische Technologien Vorteile: Übertragungsformat stark strukturiert Verschlüsselte Übertragung möglich Ausgereifte Protokollmechanismen vorhanden Nachteile: Zugeschnitten auf Bedürfnisse von Handel, Banken, Weniger geeignet für Mix strukturiert/unstrukturiert Aufwändiger Konverter erforderlich Hoher Aufwand bei Änderungen am Datenformat I.d.R. keine digitale Signatur vorgesehen Fazit: Für branchenübergreifende Kommunikation sowie B2C- und rechtsverbindliche G2C-Kommunikation eher ungeeignet :18; Seite 17

18 2 assische Technologien Fazit Die klassischen Technologien erfüllen die Anforderungen an den rechtsverbindlichen Austausch von Dokumenten nur teilweise :18; Seite 18

19 3 Analyse von Initiativen mit govlink-ähnlichem Anforderungsprofil andardisierungs-initiativen Standardisierungsgremien W3C; BizTalk-Framework; ebxml E-Government-Initiativen Grossbritannien; Deutschland; Initiativen der schweizerischen Post Tumbleweed; Mosaic Initiativen im Rechtsumfeld Lexml; LegalXML :18; Seite 19

20 3 andardisierungs-initiativen Fazit Standardisierungs-Initiativen erfüllen die Anforderungen an den rechtsverbindlichen Austausch von struturierten Dokumenten nur teilweise. Insbesondere fehlen Funktionen / Konzepte für die Protokollierung von Zustellungen durch einen vertrauenswürdigen Dritten (virtuelle Poststelle, Intermediär) :18; Seite 20

21 4 Eigener Transport-Standard (GovLink-Standard) genentwicklung Spezifikation eines eigenen Transport-Standards Intermediär-/Hub-Architektur Teilnehmerverwaltung (Closed User Group) Protokollierung von Zustellungen (Quittungen) Signature Encryption Proof Of Concept bestehend aus : Java APIs zum Transportstandard; Intermediär; Anwaltsclient :18; Seite 21

22 5 CI 1.2 OSCI-Standard V1.2 (Herbst 02) Veröffentlichung des deutschen OSCI-Standards V1.2 Vergleich zwischen OSCI V1.2 und GovLink-Standard GovLink-Standard wird vorerst eingefroren Gründe zugunsten von OSCI: Inhaltliche Äquivalenz Grössere Chance einer europäischen Verbreitung Ökonomische Überlegungen bezüglich der Pflege :18; Seite 22

23 Kapitel 4 OSCI (Online Services Computer Interface) 4.1 Einführung OSCI 4.2 Eigenschaften von OSCI Der europäische Standard, der die GovLink Anforderungen weitgehend abdeckt :18; Seite 23

24 1 Entstehung von OSCI nführung OSCI Bund Online 2005: Ziel der E-Government-Strategie der deutschen Bundesverwaltung: 400 Dienstleistungen/Verfahren des Bundes online Städtewettbewerb Wettbewerb im Rahmen von Bund Online 2005 Sieger: OSCI-Standard der Stadt Bremen Zuständigkeit für Pflege und Weiterentwicklung: OSCI-Leitstelle Bremen :18; Seite 24

25 1 nführung OSCI Empfehlungen für OSCI Standard Europäische Kommission: Würdigung von OSCI als vorbildliche e-government-initiative (Deutsches) Bundesamt für Sicherheit in der Informationstechnik: Bescheinigung der Tauglichkeit des Standards für e-government (Deutsches) Bundesministerium des Innern: OSCI als verbindlicher Standard für e-government-transaktionen :18; Seite 25

26 2 genschaften von OSCI Bestandteile von OSCI Beschreibung des Nachrichtenaustauschs Rollenmodell Schichtenmodell Authentifizierung der Kommunikationspartner Intermediär Kommunikationsszenarien Sicherheitskonzept Digitale Signatur Verschlüsselung Reaktionsvorschriften und Rückmeldungen Protokollierung / Quittungen Nachrichtenaufbau :18; Seite 26

27 2 OSCI-Rollenmodell genschaften von OSCI Sig.-Zert. Sig.-Zert. Autor Sender erzeugt verfasst generiert erzeugt Inhaltsdatensignatur Inhaltsdaten Nutzdaten Nutzdatensignatur Inhaltsdatencontainer Nutzdatencontainer verschlüsselt (verschlüsselter) Inhaltsdatencontainer (verschlüsselter) Nutzdatencontainer verschlüsselt OSCI-Nachricht verifiziert Leser kann entschlüsseln empfängt kann entschlüsseln Empfänger verifiziert optional zwingend validiert validiert :18; Seite 27

28 2 OSCI-Schichtenmodell genschaften von OSCI Autor Autor Leser Leser Sender Empfänger OSCI-Transport 1.2 Client Nachrichtensender/ -empfänger Supplier / Client Nachrichtensender/ -empfänger Supplier / Client Nachrichtensender/ -empfänger Technische Transportschicht Technische Transportschicht Technische Transportschicht Benutzer 1 Intermediär Benutzer :18; Seite 28

29 2 genschaften von OSCI OSCI-Intermediär - Aufgaben Protokollierung des Meldungsverkehrs Auslieferung von Quittungen (Laufzettel) zum Meldungsverkehr Zertifikatsprüfung Verwaltung der Postfächer :18; Seite 29

30 2 Kommunikationsszenarien: One-Way-Message, aktiver Empfänger genschaften von OSCI Benutzer 1 Intermediär Benutzer 2 Zustellungsauftrag Zustellungsantwort Abholauftrag Abholantwort Zustellung der Meldung durch den Sender an den Intermediär. Empfänger holt Meldung beim Intermediär ab :18; Seite 30

31 2 Kommunikationsszenarien: One-Way-Message, passiver Empfänge genschaften von OSCI Benutzer 1 Intermediär Benutzer 2 Weiterleitungsauftrag Annahmeauftrag Annahmeantwort Weiterleitungsantwort Zustellung der Meldung durch den Sender an den Intermediär. Intermediär leitet Meldung sofort an den Empfänger weiter :18; Seite 31

32 2 Kommunikationsszenarien: Request-Response, passiver Empfänger genschaften von OSCI Benutzer 1 Intermediär Benutzer 2 Abwicklungsauftrag Bearbeitungsauftrag Bearbeitungsantwort Abwicklungsantwort :18; Seite 32

33 2 Authentifizierung der Kommunikationspartner (Dialog-Protokoll) genschaften von OSCI Authentifizierung durch Zertifikat Bei jedem Schritt in einer OSCI-Session wird die Benutzerauthentizität und Meldungsreihenfolge sichergestellt OSCI benötigt keinen verschlüsselten Transportkanal (SSLT), weil die ganze Meldung ohnehin verschlüsselt wird (sog. doppelter Umschlag) :18; Seite 33

34 2 genschaften von OSCI Sicherheitskonzept (Zertifikatsniveau) Fortgeschrittene Signatur Das Zertifikat ist auf einer Diskette oder dem PC gespeichert (Soft-Zertifikat) Qualifizierte Signatur (GovLink) Das Zertifikat befindet sich auf einer Smartcard Akkreditierte Signatur Qualifizierte Signatur mit Zertifikat eines akkreditierten Zertifikatsanbieters :18; Seite 34

35 2 Reaktionsvorschriften und Rückmeldungen genschaften von OSCI Fehlermeldungen auf Nachrichtenebene Rückmeldungen auf Auftragsebene :18; Seite 35

36 2 Protokollierung / Quittungen genschaften von OSCI Der Intermediär führt zu jeder Zustellung einen Laufzettel. Protokollierung: Zeitpunkt der Einreichung beim Intermediär Zeitpunkt der Weiterleitung an den Empfänger beziehungsweise die Abholung durch den Empfänger Gültigkeit der verwendeten Zertifikate Der (signierte) Laufzettel kann jederzeit vom Sender oder Empfänger beim Intermediär angefordert werden :18; Seite 36

37 2 genschaften von OSCI In OSCI verwendete Standards W3C-Standards: SOAP im Document-Style mit Attachments XML-Encryption zur Verschlüsselung von XML- Dokumenten XML-Signature zur Signatur von XML-Dokumenten Security: RSA SHA-1 Two-Key-Triple-DES / Aes-128 /192 /256 X509v3 Zertifikate :18; Seite 37

38 2 genschaften von OSCI Nachrichtenaufbau (doppelter Umschlag) <Envelope> Nachrichtenumschlag <Header> </Header> <Envelope> Nachrichtenumschlag <Header> Signatur Gesamtnachricht Verarbeitungselemente </Header> <Body> <Body> Verschlüsselungskopf Inhaltsdatencontainer </Envelope> </Body> HREF Attachment Hashwert1 Attachment </Envelope> Inhaltsdatencontainer n </Body> HREF Attachment 1 Hashwert1 Attachment 1 Attachment :18; Seite 38

39 Kapitel 5 OSCI-Implementierung 5.1 OSCI Produkte 5.2 OSCI im praktischen Einsatz Ohne Implementierung läuft gar nichts! :18; Seite 39

40 1 CI Produkte Governikus von bremen-online-services Bausteinlösung für kommunale Anwendungen Sehr enge Zusammenarbeit zwischen der OSCI- Leitstelle und bremen-online-services Der aktuelle Governikus Release 1.1 implementiert die inoffizielle OSCI-Version 1.1 Ende 2003 wird Governikus 2.0 mit der Implementierung von OSCI 1.2 auf dem Markt erscheinen :18; Seite 40

41 1 Frei verfügbare OSCI-Programm-Bibliothek CI Produkte Basismodule für die Abwicklung einer rechtsverbindlichen elektronischen Kommunikation mit OSCI 1.2 sind von der OSCI Leitstelle bei bremen-online-services in Auftrag gegeben worden (Verfügbarkeit Ende 2003) :18; Seite 41

42 2 Verbreitung von OSCI basierten Governikus-Anwendungen CI im praktischen Einsatz Finanzämter Gerichte Hochschulen (Bremen; Bremerhaven) Deutsche Post AG Deutsche Telekom AG UNICEF Sparkasse Bremen Diverse Amtsstellen (Stadtplanung und Bauamt; Kfz- Zulassungsstelle; Standesamt; Stadtamt) Diverse Private (Zeitungsverlage; Fussballvereine) :18; Seite 42

43 2 OSCI-Implementation Meldewesen CI im praktischen Einsatz Meldewesen (Einwohnerkontrolle): OSCI-XMeld Elektronische Abwicklung von An- und Abmeldungen bei Gemeinden über das Internet: Einfache Melderegister-Auskunft Rückmeldung Melderegister-Nachführung Standardisierung von Inhaltsdaten Im Auftrag der deutschen Bundesregierung wird OSCI-XMeld, ein standardisierter Datenaustausch im Meldewesen, entwickelt (OSCI-Transport für die Übermittlung / OSCI-XMeld für strukturierte Inhaltsdaten) :18; Seite 43

44 2 OSCI-Implementation Justizbereich CI im praktischen Einsatz Justizbereich: OSCI-XJustiz Die deutsche Justizministerkonferenz plant eine Standardisierung der Inhaltsdaten im juristischen Bereich, als Voraussetzung eines bundesweit einheitlichen elektronischen Rechtsverkehrs. Analoges Projekt zu JusLink in der Schweiz :18; Seite 44

45 Kapitel 6 Zusammenfassung / Ausblick 6.1 Zusammenfassung 6.2 Ausblick Was nun? :18; Seite 45

46 1 Zusammenfassung sammenfassung Ausgangssituation im Projekt GovLink Mehrere Anwendungen benötigen rechtsverbindlichen Transport von Dokumenten Anforderungen an den rechtsverbindlichen Dokumenten-Austausch Eingeschriebener Brief Nichtabstreitbarkeit; Authentizität; Integrität; Vertraulichkeit Protokollierung und Quittierung der Übermittlungszeitpunkte Lösungssuche Klassische Technologien; Initiativen mit ähnlichem Anforderungsprofil; Eigenentwicklung; ökonomische Überlegungen führen zu OSCI OSCI Der deutsche (europäische) Standard, der die GovLink Anforderungen weitgehend abdeckt OSCI-Implementierung Implementierung des OSCI 1.2 Standards durch bremen-online-services bis Ende :18; Seite 46

47 2 sblick Ausblick GovLink (OSCI) Präsentation und Vorstellung von OSCI bei ISB, Guichet virtuel, den Kantonen und interessierten Organisationen In welchen Bereichen soll OSCI zum verbindlichen Standard werden? Zusammenarbeit der Schweiz mit OSCI-Leitstelle etablieren (Vertretung der CH-Interessen bei der Weiterentwicklung) Technische Zusammenarbeit mit bremen-online-services (Einflussnahme auf Weiterentwicklung Governikus) Spezifikation des Deltas von GovLink/JusLink Anforderungen (Gültigkeitsdauer der Meldungen; Teilnehmerverwaltung) Realisierung PKI-Anbindung (PKI des BIT) :18; Seite 47

48 Wir danken für Ihre Aufmerksamkeit.