Bern 01.06.03 ein Framework für rechtsverbindlichen Austausch von strukturierten Dokumenten (Formularen)
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 10.07.2003 9:18; Seite 2
Kapitel 1 Ausgangssituation im Projekt GovLink Wie alles begann 10.07.2003 9:18; Seite 3
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) 10.07.2003 9:18; Seite 4
Gründe für die Entwicklung oder Evaluation eines Standards sgangssituation Verkürzung von Projektzeiten Interoperabilität Investitionsschutz Erreichbarkeit der kritischen Masse 10.07.2003 9:18; Seite 5
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 10.07.2003 9:18; Seite 6
Kapitel 2 Anforderungen an den rechtsverbindlichen Austausch von strukturierten Dokumenten Sicher ist nicht genug! 10.07.2003 9:18; Seite 7
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 10.07.2003 9:18; Seite 8
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 10.07.2003 9:18; Seite 9
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 10.07.2003 9:18; Seite 10
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 10.07.2003 9:18; Seite 11
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 10.07.2003 9:18; Seite 12
Kapitel Lösungsfindung 3 3.1 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 E-Mail? Welche Technologien und Architekturen kommen für den Austausch strukturierter Dokumente im Justizbereich überhaupt in Frage? 10.07.2003 9:18; Seite 13
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 10.07.2003 9:18; Seite 14
2 E-Mail (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 10.07.2003 9:18; Seite 15
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 10.07.2003 9:18; Seite 16
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 10.07.2003 9:18; Seite 17
2 assische Technologien Fazit Die klassischen Technologien erfüllen die Anforderungen an den rechtsverbindlichen Austausch von Dokumenten nur teilweise. 10.07.2003 9:18; Seite 18
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 10.07.2003 9:18; Seite 19
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). 10.07.2003 9:18; Seite 20
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 10.07.2003 9:18; Seite 21
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 10.07.2003 9:18; Seite 22
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 10.07.2003 9:18; Seite 23
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 Media@Komm: Wettbewerb im Rahmen von Bund Online 2005 Sieger: OSCI-Standard der Stadt Bremen Zuständigkeit für Pflege und Weiterentwicklung: OSCI-Leitstelle Bremen 10.07.2003 9:18; Seite 24
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 10.07.2003 9:18; Seite 25
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 10.07.2003 9:18; Seite 26
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 10.07.2003 9:18; Seite 27
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 2 10.07.2003 9:18; Seite 28
2 genschaften von OSCI OSCI-Intermediär - Aufgaben Protokollierung des Meldungsverkehrs Auslieferung von Quittungen (Laufzettel) zum Meldungsverkehr Zertifikatsprüfung Verwaltung der Postfächer 10.07.2003 9:18; Seite 29
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. 10.07.2003 9:18; Seite 30
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. 10.07.2003 9:18; Seite 31
2 Kommunikationsszenarien: Request-Response, passiver Empfänger genschaften von OSCI Benutzer 1 Intermediär Benutzer 2 Abwicklungsauftrag Bearbeitungsauftrag Bearbeitungsantwort Abwicklungsantwort 10.07.2003 9:18; Seite 32
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) 10.07.2003 9:18; Seite 33
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 10.07.2003 9:18; Seite 34
2 Reaktionsvorschriften und Rückmeldungen genschaften von OSCI Fehlermeldungen auf Nachrichtenebene Rückmeldungen auf Auftragsebene 10.07.2003 9:18; Seite 35
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 10.07.2003 9:18; Seite 36
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 10.07.2003 9:18; Seite 37
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 2 10.07.2003 9:18; Seite 38
Kapitel 5 OSCI-Implementierung 5.1 OSCI Produkte 5.2 OSCI im praktischen Einsatz Ohne Implementierung läuft gar nichts! 10.07.2003 9:18; Seite 39
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 10.07.2003 9:18; Seite 40
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). 10.07.2003 9:18; Seite 41
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) 10.07.2003 9:18; Seite 42
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). 10.07.2003 9:18; Seite 43
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 10.07.2003 9:18; Seite 44
Kapitel 6 Zusammenfassung / Ausblick 6.1 Zusammenfassung 6.2 Ausblick Was nun? 10.07.2003 9:18; Seite 45
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 2003 10.07.2003 9:18; Seite 46
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) 10.07.2003 9:18; Seite 47
Wir danken für Ihre Aufmerksamkeit.