konzept und spezifikation gesicherter formularcontainer filekonzept und spezifikation gesicherter...

www.egiz.gv.at

E-Mail: [email protected] Telefon: ++43 (316) 873 5514

Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria

Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU -Graz

Konzept und Spezifikation

Gesicherter Formularcontainer

Schwerpunktthema Neue Dienste

Version 1.0, 25.02.2008

DI Arne Tauber – [email protected]

DI Thomas Knall – [email protected]

Zusammenfassung: Der Formularcontainer – der Comfort Layer – ist eine Anwendung, die für die Bürgerin/den Bürger häufig benötigte Formularinhalte – wie Bankinformationen, Geburtsort, Anschrift oder auch Beilagen – verschlüsselt bereit hält und bei Bedarf in Webformulare automatisch einfüllt. Um die persönlichen Daten sicher zu speichern, bedient sich der Formularcontainer der Ver- bzw. Entschlüsselung durch die Bürgerkarte. Der Comfort-Layer soll nicht ausschließlich auf E-Government Formulare beschränkt sein, sondern beliebige Webformulare, aber auch Formulare in anderen Standardapplikationen wie Adobe PDF bedienen können.

mailto:[email protected]

mailto:[email protected]


Schwerpunktthema Neue Dienste Inhaltsverzeichnis

– 2 –

Inhaltsverzeichnis

1 Einleitung .......................................................................................................................................... 6 1.1 Schlüsselwörter 6 1.2 Geschlechtsspezifische Bezeichnungen 6 1.3 Begriffsdefinitionen 6

1.3.1 Formularcontainer ............................................................................................ 6 1.3.2 Avatar .............................................................................................................. 6 1.3.3 Comfort-Layer .................................................................................................. 6 1.3.4 Datenspeicher .................................................................................................. 6

1.4 Motivation 7 1.5 Anforderungen 7 1.6 Konzept Formularcontainer 8

1.6.1 Exemplarischer Ablauf ....................................................................................10

2 Datenspeicher für Formularinhalte .................................................................................................12 2.1 Lokal/Serverseitig 12 2.2 Verschlüsselt/Unverschlüsselt 12 2.3 Zugang über Identifikation/Authentifizierung 12 2.4 Zugriff 13

3 Lokaler Comfort-Layer ....................................................................................................................14 3.1 Einleitung 14 3.2 Prozessmodell 14 3.3 Serviceschnittstellen und Transportprotokolle 16 3.4 GUI Interaktionen 16

4 Serverseitiger Comfort-Layer ..........................................................................................................17 4.1 Einleitung 17 4.2 Prozessmodell 18 4.3 Zentrale Portallösung 19

5 Beispiele für Avatar Ausprägungen ................................................................................................20 5.1 Avatare mit clientseitigem Comfort Layer 20

5.1.1 Browser Avatar................................................................................................20 5.1.2 PDF Avatar .....................................................................................................21 5.1.3 Microsoft Office Avatar ....................................................................................21

5.2 Avatare mit serverseitigem Comfort-Layer 21 5.2.1 Browser Avatar................................................................................................21

6 Schnittstelle Comfort-Layer ............................................................................................................22 6.1 Prozessablauf 22 6.2 Kommunikation 23

6.2.1 Übertragung mittels HTTP(s) POST Parametern .............................................23 6.3 XML Schnittstelle 24

6.3.1 Anfrage zum Auslesen von Formulardaten ......................................................24 6.3.2 Antwort ............................................................................................................26 6.3.3 Anfrage zum Aktualisieren bzw. Sichern von Formulardaten ...........................26 6.3.4 Antwort ............................................................................................................27

7 Infobox Datenformat .......................................................................................................................28 7.1 Infobox Struktur 28

7.1.1 Schlüssel .........................................................................................................28 7.1.2 Globale Formulardaten für E-Government Formulare......................................28 7.1.3 Beispiel ...........................................................................................................29

7.2 Verschlüsselung 29 7.2.1 Comfort-Layer ist eine Komponente der Bürgerkartenumgebung ....................29 7.2.2 Comfort-Layer ist keine Komponente der Bürgerkartenumgebung ..................29

7.3 XML Spezifikation 30 7.3.1 Formulardaten in unverschlüsselter Form .......................................................30 7.3.2 Formulardaten in verschlüsselter Form ...........................................................31 7.3.3 Globale Infobox ...............................................................................................31

Anhang ...................................................................................................................................................32 Beispiele zur XML Schnittstelle 32


Schwerpunktthema Neue Dienste Inhaltsverzeichnis

– 3 –

Auslesen von Formulardaten (Request) ........................................................................32 Auslesen von Formulardaten (Antwort) .........................................................................32 Sichern von Formulardaten (Request) ...........................................................................32 Sichern von Formulardaten (Antwort – Erfolgsfall).........................................................33 Sichern von Formulardaten (Antwort – Fehler) ..............................................................33

Beispiele zum XML Infobox Format 33 Unverschlüsselte Formulardaten ...................................................................................33 Unverschlüsselte Formulardaten mit Referenz auf globale Infobox ...............................33 Verschlüsselte Formulardaten .......................................................................................34 Beispiel für eine globale Infobox ....................................................................................34

Referenzen .............................................................................................................................................35


Schwerpunktthema Neue Dienste Abbildungsverzeichnis

– 4 –

Abbildungsverzeichnis

Abb. 1.1: Strukturbild des Formular-Avatars ........................................................................................... 9 Abb. 1.2: Online Formular gemäß Styleguide ....................................................................................... 10 Abb. 1.3: Online Formular mit exemplarischen Button zur Aktivierung des Formular-Avatars ............. 11 Abb. 1.4: Online Formular vorbefüllt durch Formular-Avatar ................................................................ 11 Abb. 3.1: Modell eines clientbasierten Comfort-Layers ......................................................................... 15 Abb. 4.1: Modell eines serverbasierten Comfort-Layers ....................................................................... 18 Abb. 6.1 Prozessablaufdiagramm ......................................................................................................... 22 Abb. 6.2 ReadFormDataRequest .......................................................................................................... 25 Abb. 6.3 FormType ................................................................................................................................ 25 Abb. 6.4 ReadFormDataResponse ....................................................................................................... 26 Abb. 6.5 UpdateFormDataRequest ....................................................................................................... 26 Abb. 6.6 UpdateFormDataResponse .................................................................................................... 27 Abb. 7.1 FormDataContainer................................................................................................................. 30


Schwerpunktthema Neue Dienste Revision History

– 5 –

Revision History

Version Datum Autor(en)

0.1 25.01.2008 A.T., T.K. Initialversion

0.2 07.02.2008 T.K. Motivation, Server CL

0.3 07.02.2008 A.T. Konzept, Lokaler CL, Schnittstelle, Infobox Spezifikation, Datenablage

0.4 07.02.2008 A.T. Anhang, Beispiele

0.5 07.02.2008 A.T. Begriffsdefinitionen

0.6 08.02.2008 A.T. Referenzen auf globale Infobox, Beispiele

0.7 08.02.2008 T. K. Formatierungen, Durchsicht

0.8 21.02.2008 A.T. Finale Durchsicht

0.9 25.02.2008 A.T. Korrekturen

1.0 25.02.2008 A.T. Finalisierung.


Schwerpunktthema Neue Dienste Einleitung

– 6 –

1 Einleitung

1.1 Schlüsselwörter

Dieses Dokument verwendet die Schlüsselwörter MUSS, DARF NICHT, ERFORDERLICH, SOLLTE, SOLLTE NICHT, EMPFOHLEN, DARF und OPTIONAL zur Kategorisierung der Anforderungen. Diese Schlüsselwörter sind analog zu ihren englischsprachigen Entsprechungen MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY und OPTIONAL zu handhaben, deren Interpretation in [KEYWORDS] festgelegt ist.

1.2 Geschlechtsspezifische Bezeichnungen

Alle Personenbezeichnungen, die in diesem Dokument in der männlichen Form verwendet werden, gelten sinngemäß auch für die weibliche Form.

1.3 Begriffsdefinitionen

1.3.1 Formularcontainer

Der Begriff Formularcontainer bezeichnet ein Konzept, welches das Ausfüllen von Formularen erleichtern soll. Die Daten, die letztlich zum Ausfüllen herangezogen werden, werden entweder von etablierten Registern vorgehalten, zum Beispiel ZMR, FB etc. sofern zugänglich, oder verschlüsselt im Rahmen der Bürgerkarte1 bzw. Bürgerkartenumgebung gespeichert. So soll jedes geeignete E-Government und E-Business Online-Formular mit den derart hinterlegten Daten automatisch befüllt werden können.

1.3.2 Avatar

Ein Avatar bezeichnet jene Komponente, die in der Umgebung des Formulars arbeitet und für das Befüllen und Sichern der Formulardaten zuständig ist. Diese Komponenten können unterschiedliche Formen annehmen, z.B. als Plugin für einen Browser, Adobe Acrobat PDF oder Microsoft Office. Über automatisiertes Erkennen oder manuelles Interagieren des Benutzers werden Formulardaten über die Comfort-Layer Schnittstelle aus den entsprechenden Datenspeichern ausgelesen bzw. gesichert.

1.3.3 Comfort-Layer

Der Comfort-Layer ist eine Softwarekomponente, die lokal oder serverseitig läuft und Anfragen zum Auslesen bzw. Sichern von Formulardaten seitens Avataren bearbeitet. Er ist zuständig für das Auslesen und Sichern dieser Daten aus bzw. in entsprechende Datenspeicher und stellt daher Avataren eine standardisierte Schnittstelle zur Verfügung.

1.3.4 Datenspeicher

Als Datenspeicher werden Container bezeichnet, die gesicherte Formulardaten halten und diese bei einem Zugriff seitens des Comfort-Layers zur Verfügung stellen bzw. ablegen. Datenspeicher könnten unterschiedlichste Formen annehmen. So können Dateien im lokalen Filesystem, (dislozierte2) Infoboxen, Datenbanken, USB-Sticks usw. als Datenspeicher dienen. Für die Kommunikation und den Zugriff auf diese Datenspeicher ist alleinig der Comfort-Layer zuständig.

1 http://www.buergerkarte.at/

2 http://demo.egiz.gv.at/plain/projekte/optimierung_und_erweiterung_buergerkarte/dislozierte_infoboxen

http://www.buergerkarte.at/

http://demo.egiz.gv.at/plain/projekte/optimierung_und_erweiterung_buergerkarte/dislozierte_infoboxen



– 7 –

1.4 Motivation

Formulare werden – zumindest papierbasiert – seit jeher als standardisiertes Mittel zur Erhebung von Daten, sei es von Behörden oder Unternehmen, eingesetzt. Formulare helfen Mehrdeutigkeiten zu vermeiden und können schnell und einfach auf Vollständigkeit geprüft werden. Mit dem Aufkommen elektronischer Formulare (Web-Formulare, Adobe Acrobat PDF, XPS...) vergrößert sich der Nutzen um die Möglichkeit, diese dynamisch auszuführen, Hilfestellungen anzubieten, sofortige Verifikation auf Gültigkeit der eingegeben Daten durchzuführen und um Formulardaten automatisiert zu verarbeiten, was sowohl Bearbeitungszeit als auch Kosten reduziert.

Aufgrund dieser Vorteile bieten Behörden zunehmend elektronische Formulare an um Anfragen seitens der BürgerInnen entgegenzunehmen. Gewöhnlich sind dies typische Antragsformulare für Anbringen, die immer wiederkehrende Datenfelder (sogenannte "Standarddaten") enthalten. Standarddaten sind meistens Angaben zur Person, d.h. persönliche Daten wie Familienname, Vorname, Geburtsdatum, Geschlecht oder aber auch Adressdaten wie Straße, Ort, Postleitzahl oder E-Mail-Adresse. Diese wiederkehrenden Daten wurden erkannt, identifiziert und bezüglich Benennung, Typ, Wertebereich und Darstellung normiert (siehe [ST-DAT1.2]).

Obwohl Familienname, Vorname und Geburtsdatum im Regelfall mit den Daten aus der Personenbindung der AntragstellerIn befüllt werden, verbleiben aus Sicht des Anwenders immer noch viele potentielle Standarddatenfelder, die stets händisch ausgefüllt werden müssen. Eine Lösung ist einfach: Formularfelder automatisiert ausfüllen. Diese Idee ist nicht neu, wie beispielsweise die zahlreich verfügbaren Erweiterungen für den Browser Firefox zeigen3: Formfiller, Autofill Forms, Form Saver, InFormEnter, AutoFormer, fireform, AI Roboform Toolbar for Firefox. Wie und wo die vorgegeben Daten jedoch schließlich gespeichert werden, ist kaum dokumentiert.

An dieser Stelle setzt das Konzept Formularcontainer unter Zuhilfenahme der Bürgerkarte an. Zum einen ermöglicht die Bürgerkarte einen Anwender eindeutig zu identifizieren und authentifizieren, zum anderen können persönliche Daten mit dem öffentlichen Zertifikat der Bürgerkarte des Anwenders verschlüsselt werden und sind dann ausschließlich über eine Entschlüsselung mit Bürgerkarte zugänglich. In diesem Fall spielt es dann auch keine Rolle mehr, wo diese Daten abgelegt werden. Ziel dieses Dokuments ist der Entwurf eines Konzepts und einer Spezifikation für einen Mechanismus zum Speichern und Abrufen persönlicher Daten im Zusammenhang mit der Bürgerkarte.

1.5 Anforderungen

Der Formularcontainer ist ein Konzept, das für die Bürgerin/den Bürger häufig benötigte Formularinhalte – wie Bankinformationen, Geburtsort oder Anschrift – verschlüsselt bereit hält und bei Bedarf in Webformulare automatisch einfüllt.

Um die persönlichen Daten sicher zu speichern, kann sich das Konzept Formularcontainer der Ver- bzw. Entschlüsselung durch die Bürgerkarte bedienen. Datenspeicher können so entweder bei einem beliebigen Dienstleister (auf Basis dislozierter Infoboxen) oder aber auch in Form eines lokalen Datencontainers – lokal bei der Anwenderin/beim Anwender – realisiert werden. Zur automatischen Befüllung von Formularen sind verschiedene technische Umsetzungsformen denkbar.

Das Konzept Formularcontainer soll letztlich beliebige Webformulare bedienen können und so nicht ausschließlich auf E-Government-Formulare beschränkt bleiben.

3 siehe auch https://addons.mozilla.org/

https://addons.mozilla.org/en-US/firefox/addon/1882









https://addons.mozilla.org/



– 8 –

1.6 Konzept Formularcontainer

Das Konzept Formularcontainer soll das Ausfüllen von Formularen erleichtern. Die Daten, die letztlich zum Ausfüllen herangezogen werden, werden entweder von etablierten Registern vorgehalten, zum Beispiel Zentrales Melderegister (ZMR), Firmenbuch etc. sofern zugänglich, oder verschlüsselt im Rahmen der Bürgerkarte bzw. Bürgerkartenumgebung gespeichert. So soll jedes geeignete E-Government und E-Business Online-Formular mit den derart hinterlegten Daten automatisch befüllt werden können. Das Ablegen von Formularfeldern zur späteren Wiederverwendung ist dabei ein von der BürgerIn gesteuerter Prozess, d.h. dass nur jene Felder und Daten gespeichert und vorgehalten werden, bei denen die BürgerIn dies ausdrücklich wünscht. So ist die BürgerIn stets in der Kontrolle der persönlichen Daten. Voraussetzung zum Einsatz des Formularcontainers im Zusammenhang mit E-Government Formularen ist, dass die betreffenden Formulare und deren Elemente entsprechend automatisch identifizierbar sind. Dazu ist ein bekanntes Merkmal bei jedem Formularelement erforderlich (siehe [ST-DAT1.2]). Bei E-Government-Formularen – das sind in der Regel Formulare, die der Styleguide-Konvention 2.x folgen und deren Elemente entsprechend identifizierbar sind – ist daher die Festlegung einer geeigneten Nomenklatur, d.h. die Definition der Art und Weise, wie wiederkehrende Standard-Formularfelder bezeichnet und identifiziert werden müssen, sinnvoll. Die so festgelegte Nomenklatur muss dann den einzelnen Formularfeldern hinzugefügt werden, wobei dies im Rahmen von HTML-Formularen entweder durch den

Namen (name Attribut) des Formular-Feldes selbst oder durch Hinzunahme eines anderen

adäquaten Attributes (bspw. id Attribut) realisiert werden kann. So „standardisierte“

Formulare wären einfach automatisiert vorbefüllbar. Das Konzept Formularcontainer kann letztlich beliebige Webformulare bedienen und soll nicht ausschließlich auf E-Government-Formulare beschränkt bleiben, um den Mehrwert dieser Komfortlösung zu maximieren. Zudem können auch alte E-Government-Formulare, die sich noch nicht einer standardisierten Nomenklatur zur Bezeichnung von Formular-Elementen bedienen, ebenfalls damit bedient werden. Daher sieht das Konzept die Unterstützung von Avataren vor, mit der nicht-styleguide-konforme Formulare – und vor allem auch privatwirtschaftliche Web-Formulare – für das Formularcontainer Konzept geeignet erfasst und die Zugehörigkeit der einzelnen Formularfelder zu den standardisierten Inhalten festgelegt werden können. Das Konzept zielt zwar in erster Linie auf Web-Formulare ab, ist aber keinesfalls darauf beschränkt zu sehen. So zum Beispiel sind auf dieselbe Art auch PDF-Formulare zu behandeln. Für diese gilt die zuvor geführte Formular Diskussion sinngemäß. Das Erkennen von automatisch identifizierbaren Formularfeldern sowie deren Befüllung wird entweder durch eine eigene Komponente – dem sog. Formular-Avatar – vorgenommen, oder aber bereits serverseitig durchgeführt, bspw. im Rahmen eines Formularservers. Die Integration der Vorbefüllung in das Formularsystem ist zwar die offensichtlichste Lösung, bedeutet jedoch andererseits einen entsprechenden Aufwand zur Erweiterung und Abänderung (bestehender) Systeme. Attraktiv ist daher besonders die Vorbefüllung anhand eines separaten Formular-Avatars, der auf verschiedene Arten und Weisen realisiert werden kann. Der Formular-Avatar kann einerseits in Form eines lokalen Client-Tools realisiert werden. Ein derartiger lokaler Avatar könnte durch die AnwenderIn lokal auf ein angezeigtes Web- oder PDF-Formular angewendet werden, um so das dargestellte Formular zu befüllen4. Um

4 Ähnliche Werkzeuge sind zur automatischen Befüllung mit Benutzername/Passwort frei im Web

erhältlich.



– 9 –

jedoch die Installation zusätzlicher Software bei der AnwenderIn nicht unbedingt voraussetzen zu müssen, werden jedenfalls auch Web-basierte Avatare unterstützt, die beliebige Formulare darstellen und vorbefüllen können. Ein derartiges Service wäre zum Beispiel im Rahmen der Service-Leistungen von HELP.gv.at denkbar.

Abb. 1.1: Strukturbild des Formular-Avatars

Allen Avatar-Varianten gemeinsam ist, dass die Vorhaltung der Daten zur Vorbefüllung nicht im Rahmen des Formular-Avatars selbst erfolgt. Wie schon in Abbildung Abb. 1.1 skizziert, sind die Daten zur Vorbefüllung durchaus verteilt zu sehen (Daten stammen sowohl aus Registern als auch aus einem persönlichen Datenspeicher der BürgerIn). Daher wurde ein allgemeines und offenes Konzept entworfen, damit die verschiedensten Avatare auf eine standardisierte Weise darauf zurückgreifen können. Das Konzept berücksichtigt vor allem die BürgerIn als diejenige Instanz, die die alleinige Kontrolle über diese Daten hält (zum Beispiel über Verschlüsselung mit der Bürgerkarte). Aus logischer Sicht erfolgt der Zugriff auf die Daten über eine standardisierte Schnittstelle, ungeachtet von wo die einzelnen Datenelemente letztlich bezogen werden. Die persönlichen Formulardaten der BürgerIn sollen sinnvollerweise verschlüsselt im Rahmen der Bürgerkarte gespeichert werden, d.h.in sogenannten Infoboxen. Bei den gegenwärtigen Infoboxen der Bürgerkarte können die Daten entweder nur in der Signaturkarte selbst oder im Rahmen und Umfeld der lokalen Bürgerkartensoftware abgespeichert werden. Beide Varianten erfüllen die Erwartungen in Bezug auf ablegbare Datenmengen und Mobilität nur bedingt. Daher sind derartige Daten bevorzugt in sogenannten dislozierten Infoboxen5 zu halten.

5 Dislozierte Infoboxen sind Infoboxen, auf die wie gewohnt durch die im Rahmen der

Bürgerkartenspezifikation definierten Befehle zugegriffen werden können, d.h. über die etablierte



– 10 –

Wählt der Benutzer dieses Icon aus, so werden die Formularfelder Avatar-unterstützt ausgefüllt. Zu jenen Inhalten, die erkannt werden, wird der entsprechende Inhalt aus dem Formularcontainer Datenspeicher – zum Beispiel Bürgerkartenumgebung (Infobox) – geholt, entschlüsselt und in das Formular eingefügt. Um das hier beschriebene Konzept zu illustrieren, gibt der nachfolgende Abschnitt ein Anwendungsbeispiel auf Basis eines Web-Formulars aus Benutzersicht.

1.6.1 Exemplarischer Ablauf

Der Benutzer kann ein Formular direkt beim betreffenden Web-Service abrufen. In diesem Fall ist die Abfolge wie im bisher gewohnten Fall.

Abb. 1.2: Online Formular gemäß Styleguide

Ruft man dasselbe Formular in einem dem Formular Avatar unterstützenden Portal auf, dann wird von diesem ein Avatar-Service-Icon hinzugefügt.

Security-Layer-Schnittstelle, jedoch deren Inhalte je nach Wunsch auf der Signaturkarte (in weiterer Folge Bürgerkartenträger genannt) selbst, lokal in der Bürgerkartenumgebung/-software, auf einem dezidiertem, externen Speichermedium (z.B.: bestimmte Laufwerksbereiche, Netzwerkressourcen, USB-Stick, etc.) oder auf einem Infobox-Server verschlüsselt abgelegt werden können. Das Detail-Konzept dazu ist auf http://demo.egiz.gv.at verfügbar.

http://demo.egiz.gv.at/



– 11 –

Abb. 1.3: Online Formular mit exemplarischen Button zur Aktivierung des Formular-Avatars

Wählt der Benutzer dieses Icon aus, so werden die Formularfelder Avatar-unterstützt ausgefüllt. Zu jenen Inhalten, die erkannt werden, wird der entsprechende Inhalt aus dem Formularcontainer Datenspeicher – zum Beispiel Bürgerkartenumgebung (Infobox) – geholt, entschlüsselt und in das Formular eingefügt.

Abb. 1.4: Online Formular vorbefüllt durch Formular-Avatar

Der Betroffene füllt das Formular wie gewohnt weiter aus. Beim Absenden frägt der Avatar, sofern an entsprechend identifizierbaren Formularfeldern Änderungen entstanden sind, ob diese Daten/welche Daten im mit der Karte des Betroffenen verschlüsselten Daten-Container (z.B. Infobox) für eine spätere Verwendung abgespeichert werden sollen.


Schwerpunktthema Neue Dienste Datenspeicher für Formularinhalte

– 12 –

2 Datenspeicher für Formularinhalte

Dieser Abschnitt soll eine kurze Veranschaulichung über die verschiedenen Möglichkeiten des Sicherns von Formulardaten geben. Prinzipiell können Speicherorte gemäß folgenden Kriterien unterschieden werden:

1. Lokal/Serverseitig

2. Verschlüsselt/Unverschlüsselt

3. Zugang über Identifikation/Authentifizierung

4. Zugriff

a. Datenbank

b. Filesystem

c. Infobox in einer Bürgerkartenumgebung (Security-Layer [SECLAYER])

d. Chipkarte

e. usw…

Die oben angeführten Kriterien werden nun in den folgenden Abschnitten eingehender beschrieben.

2.1 Lokal/Serverseitig

Formulardaten können in lokalen Datenspeichern, aber auch serverseitig gespeichert werden. Ein lokaler Datenspeicher kann eine Festplatte aber auch ein anderes Speichermedium wie z.B. ein USB-Stick sein. Als serverseitiger Datenspeicher könnte ein zentraler Infoboxserver, eine Online Festplatte, aber auch eine Ressource im lokalen Intranet dienen. Wie der Zugriff auf die Datenspeicher erfolgt, hängt von der Implementierung des Comfort-Layers ab und ist nicht Teil dieser Spezifikation. Auch ist es dem Comfort-Layer überlassen, wie er es dem Benutzer ermöglicht, die Arten des Zugriff auf die einzelnen Speicherorte zu konfigurieren.

2.2 Verschlüsselt/Unverschlüsselt

Formulardaten können in Datenspeichern sowohl verschlüsselt als auch unverschlüsselt abgelegt werden. Eine Verschlüsselung ist aus Sicherheitsgründen in jedem Fall vorzuziehen. Hierbei muss differenziert werden, auf welcher Ebene die Verschlüsselung stattfindet. Diese kann auf Bit-Ebene der sensitiven Information durch direkte Verschlüsselung (z.B. XML Verschlüsselung [XMLENC]) erfolgen, aber auch auf Ebene des Datenträgers (Bitlocker6, EFS7, TrueCrypt8, USB Stick Encryption).

2.3 Zugang über Identifikation/Authentifizierung

Auf serverbasierten Datenspeichern ist in vielen Fällen eine Identifikation und Authentifizierung notwendig, um die Formulardaten einem bestimmten Benutzer zuordnen zu können. Im Rahmen dieses Zugangs kann zwischen verschiedenen Sicherheitsebenen der Identifizierung und Authentifizierung unterschieden werden:

6 http://technet.microsoft.com/en-us/windowsvista/aa906017.aspx

7 http://technet.microsoft.com/en-us/library/bb457065.aspx

8 http://www.truecrypt.org/

http://technet.microsoft.com/en-us/windowsvista/aa906017.aspx

http://technet.microsoft.com/en-us/library/bb457065.aspx

http://www.truecrypt.org/


Schwerpunktthema Neue Dienste Datenspeicher für Formularinhalte

– 13 –

1. Benutzername/Passwort

2. Benutzername/Passwort mit zusätzlichem Token (z.B. mobile TAN)

3. Chipkarte (oder auch Bürgerkartenfunktion mittels Security-Layer [SECLAYER])

2.4 Zugriff

Formulardaten können auf unterschiedliche Art und Weise persistent gespeichert werden. Bspw. können diese in einer Datenbank abgelegt werden, in verschiedenen Dateiformatausprägungen im Filesystem abgelegt werden oder aber auch innerhalb einer Infobox in einer Bürgerkartenumgebung gespeichert werden. Werden Formulardaten innerhalb einer Infobox abgespeichert, so kann der Benutzer bspw. entscheiden, ob diese lokal im Filesystem, auf der Bürgerkarte selbst oder serverbasiert auf einem dislozierten Infoboxserver abgelegt werden sollten. Abschnitt 7 beschreibt das Infoboxformat für das Ablegen und optionale aber empfohlene Verschlüsseln von Formulardaten innerhalb einer Infobox. Allen Ausprägungen ist jedoch gemein, dass der Comfort-Layer dafür zuständig ist, es dem Benutzer zu überlassen, welche Datenquelle und welchen Speicherort er für das Ablegen der Formulardaten konfiguriert.


Schwerpunktthema Neue Dienste Lokaler Comfort-Layer

– 14 –

3 Lokaler Comfort-Layer

Dieser Abschnitt umfasst die Konzeptbeschreibung bzw. die Spezifikation eines lokal installierten Comfort-Layers.

3.1 Einleitung

Ein lokal installierter Comfort-Layer ist eine Softwarekomponente, die am selben Gerät installiert ist, auf welchem der Benutzer ein Formular ausfüllt bzw. ein gesichertes Formular wiederherstellt. Diese Software kann unterschiedliche Ausprägungen haben, allen gemein ist jedoch, dass sie die Comfort-Layer Schnittstelle lokal zur Verfügung stellt, auf welche demnach alle Avatare Zugriff haben. Mögliche Ausprägungen eines lokalen Comfort-Layers könnten bspw. sein:

1. Eine eigenständige Software, die vom Benutzer installiert werden muss und auch über ein Trayicon dem diesem für einen vereinfachten und schnellen Zugriff zur Verfügung steht.

2. Als integraler Bestandteil einer Bürgerkartenumgebung, welche die Comfort-Layer Schnittstelle zusätzlich zur Verfügung stellt und das Auslesen bzw. Ablegen von Daten in den Infoboxen für einen schnellen Zugriff nicht über die Security-Layer (siehe [SECLAYER]) Schnittstelle implementiert.

3. Als zusätzlich installierbare Komponente eines Browsers. In dieser Ausprägung könnten Avatar und Comfort-Layer als Plugin innerhalb eines Moduls realisiert werden.

Der Comfort-Layer ist zuständig für das Bearbeiten von Anfragen seitens Avataren, um den Zugriff auf abgelegte Formulardaten bzw. das Sichern von Formulardaten zu ermöglichen. Dies umfasst folgende Aufgaben:

1. Bearbeiten von Anfragen seitens Avataren über die Comfort-Layer Schnittstelle.

2. Auswahlkontrolle der Speicherorte (Infobox, personalisierter Speicher, dislozierter Speicher usw.)

3. Zugriffsschutz auf Datenspeicher (Identifikation, Authentifizierung, Verschlüsselung)

3.2 Prozessmodell

Dieser Abschnitt beschreibt das Prozessmodell eines lokal installierten Comfort-Layers mit den einzelnen Schritten für das Auslesen bzw. Sichern von Formulardaten.



– 15 –

Abb. 3.1: Modell eines clientbasierten Comfort-Layers

Eine formularbezogene Aktion (Auslesen bzw. Sichern von Formularinhalten) wird immer von einem Avatar aus angestoßen. Der Avatar kann bspw. als Plugin in Adobe Acrobat PDF bzw. als Browser Plugin oder als Komponente von Microsoft Office realisiert sein. Aber auch alle weiteren Anwendungen können mit derartigen Avataren ausgestattet werden, falls ein entsprechender Mechanismus zur Verfügung steht. Auch könnte ein lokaler Comfort-Layer eine Avatar Funktion zur Verfügung stellen, die über Window-Handles alle Fenster in Microsoft Windows mit einem solchen Mechanismus versieht. Die genaue Ausprägung ist jedoch nicht Teil dieses Konzepts, wohlgleich alle auf demselben Mechanismus basieren, der im weiteren Verlauf eingehender beschrieben wird. Der Avatar, der zuständig ist für das Befüllen und Sichern von Formulardaten, sendet einen HTTP POST Request mit dem XML Befehl an die Schnittstelle des lokalen Comfort-Layers. Die genaue Kommunikation zwischen Avatar und Comfort-Layer ist im Abschnitt 6.2 beschrieben. Es sei hier angemerkt, dass bei einem lokalen Comfort-Layer ausschließlich die Kommunikation über direkt eingebettete XML Requests im HTTP Body sinnvoll ist. Eine Verwendung von kodierten HTTP POST Parametern (siehe Abschnitt 6.2.1) könnte zwar im Rahmen eines Browser Plugins Verwendung finden, ist jedoch aufgrund der komplexeren Kommunikationsstruktur nicht zu empfehlen. Der Comfort-Layer nimmt die Anfrage vom Avatar entgegen, prüft diese und ermöglicht anschließend einen Zugriff auf den Datenspeicher der Formulardaten. Dieser Zugriff KANN unter Umständen auch eine GUI Interaktion mit dem Benutzer erfordern, bspw. beim Entschlüsseln von Formulardaten (Angabe von Benutzername/Passwort, Bürgerkarten PIN) oder auch bei der Auswahl des Speicherortes, falls mehrere solcher konfiguriert wurden (Infobox innerhalb einer Bürgerkartenumgebung/Personal Storage, usw.). Im Erfolgsfall werden die ausgelesenen Formulardaten XML kodiert als HTTP POST Antwort an den Avatar zurückgeliefert. Das Format dieser Formulardaten ist im Abschnitt 5 beschrieben.

(dislozierte) Infoboxverschlüsselt

unverschlüsselt

ZMR,

FirmenbuchBKU

Personal

Storage

Schnittstelle (HTTP / XML)

Avatar #1

Acrobat-PDF Plugin

Avatar #2

Browser Plugin

Avatar #3

Microsoft Office Plugin

CLIENT-Anwendung

Lokaler Comfort Layer



– 16 –

Im Falle eines Fehlers beim Auslesen der Formulardaten (Authentifizierung fehlgeschlagen, keine Schreibrechte, Formulardaten nicht verfügbar, usw.) wird eine entsprechende Fehlermeldung an den Avatar zurückgeliefert.

3.3 Serviceschnittstellen und Transportprotokolle

Ein lokaler Comfort-Layer MUSS bzw. KANN folgende Serviceschnittstellen über folgende Transportprotokolle zur Verfügung stellen:

1. HTTP POST Service auf Port 3497 (ERFORDERLICH)

2. HTTPS POST Service auf Port 3498 (OPTIONAL)

Die Services dürfen nur aus Sicherheitsgründen nur von localhost bzw. 127.0.0.1 aus zugänglich sein. Die Einführung dieser standardisierten Schnittstellen soll einen einheitlichen und implementierungsunabhängigen Zugriff auf unterschiedliche Ausprägungen von Comfort-Layern ermöglichen. Ein Avatar, der einen lokalen Comfort-Layer kontaktiert, kann somit immer auf dessen Services über die standardisierten Ports zugreifen, egal welche Implementierung dahinter steckt.

3.4 GUI Interaktionen

Die Bandbreite an GUI Interaktionen und Konfigurationsmöglichkeiten kann abhängig von der Implementierung variieren. Die folgende Auflistung soll mögliche Interaktionen und Konfigurationsmöglichkeiten für einen lokalen Comfort-Layer aufzeigen:

Auswahl des Speicherortes Ein Comfort-Layer kann dem Benutzer ermöglichen, interaktiv zu entscheiden, wo die Formulardaten abgelegt werden sollen. Z.B. im lokalen Filesystem (Personal Storage), in einer Infobox lokal oder auf einem dislozierten Infoboxserver, in einer Datenbank, usw.

Auswahl der Verschlüsselung Wird z.B. die Sicherung innerhalb einer Bürgerkartenumgebung oder eines Personal Storage gewählt, kann der Comfort-Layer es dem Benutzer überlassen, ob die Daten verschlüsselt oder unverschlüsselt ablegen werden sollen. Auch die Art der Verschlüsselung könnte interaktiv wählbar sein (passwortbasierte Verschlüsselung, Verschlüsselung über Chipkarte/Bürgerkarte).

Automatisiertes Ersetzen von fehlenden Formulardaten Macht der Comfort-Layer von einem globalen Datenspeicher Gebrauch, d.h. es wurde ein Container definiert, der für E-Government Formulare allgemeine Daten wie Personendaten oder Adressdaten enthält, könnte der Benutzer entscheiden, ob bei fehlenden Formulardaten diese aus dem globalen Container entnommen und in der Antwort an den Avatar enthalten sein sollen.

Unzählige weitere Szenarien wären denkbar, jedoch hängen die Interaktions- und Konfigurationsmöglichkeiten, welche dem Benutzer zur Verfügung stehen, einzig und allein von der Implementierung des Comfort-Layers ab.


Schwerpunktthema Neue Dienste Serverseitiger Comfort-Layer

– 17 –

4 Serverseitiger Comfort-Layer

Dieser Abschnitt umfasst die Konzeptbeschreibung bzw. die Spezifikation eines serverbasierten Comfort-Layers.

4.1 Einleitung

Die in Abschnitt 3 vorgestellte clientbasierte Lösung erfordert eine lokale Installation des Comfort-Layers beim Anwender. Die Software wird im Hintergrund ausgeführt und nimmt HTTP/XML-Anfragen vom Avatar (z.B. Browser-Plugin) entgegen. Die Durchführung einer lokalen Installation sowie die Abhängigkeit der Avatare vom Comfort-Layer stellt jedoch unter Umständen einen gewissen Komfort-Verlust für den Anwender dar. Eine serverbasierte Variante ermöglicht eine Nutzung des Comfort-Layers ohne dass die Clients lokale Software-Installationen vorzunehmen haben. Software-Installationen werden unter Umständen in Umgebungen mit eingeschränkten Benutzerrechten, wie z.B. Internet-Cafes, verhindert.

Die grundsätzlichen Unterschiede zu einem lokalen Comfort-Layer wären:

Der Wirkungsbereich des Comfort-Layers beschränkt sich auf Web-Applikationen.

Clientseitig muss keine Software installiert werden.

Der Comfort-Layer fügt automatisch einen Avatar in Form eines Buttons, Links oder Symbols in das Web-Formular für die Clients ein. Die Clients können ihren Avatar dann durch Klick auf den Button aufrufen bzw. durch Klick das Formular befüllen).

Der serverbasierte Comfort-Layer bietet genauso wie der lokale Comfort-Layer die in Abschnitt 6.3 spezifizierte HTTP/XML-Schnittstelle an. Anfragen werden zwar sowohl in Form direkter XML-Requests als auch in Form von HTTP(s) POST Parametern (siehe Abschnitt 6.2.1) entgegen genommen, sinnvoll verwendbar ist jedoch nur letztere Möglichkeit. Aus diesem Grund SOLLTEN direkte XML-Requests mit entsprechender Fehlermeldung (ErrorResponse) quittiert werden.

Dem serverseitigen Comfort-Layer obliegt ebenfalls die Auswahl der Speicherorte sowie der Zugriffsschutz (Identifikation, Authentifizierung, Verschlüsselung) der Speicher, jedoch müssen hier die Workflows komplett browserbasiert durchgeführt werden.

Vergleichbar mit dem lokalen Comfort-Layer sind auch bei der serverseitigen Version unterschiedlichste Ausprägungen denkbar:

Ausführung als Plugin eines Formular-Servers. Die Trennung von Formular-Inhalt und Formular-Layout, die über einen Formular-Server gegeben ist, schafft ideale Voraussetzungen für einen Comfort-Layer in Form einer Software-Erweiterung.

Ausführung eines Proxys vor einem Web-Server. Ein Comfort-Layer in der Ausführung eines Proxys müsste sämtliche Formularseiten nach Formularfeldern parsen und ggf. die Inhalte ersetzen. Dies ist eine Möglichkeit, stellt jedoch einen wesentlich größeren Aufwand im Vergleich zu einem Plugin eines Formular-Servers dar.

Ausführung als Web-Server-Modul. Analog zu einem Proxy könnte ein Comfort-Layer genauso als Modul für einen Web-Server (z.B. als Apache-Modul9) implementiert werden.

9 http://modules.apache.org/

http://modules.apache.org/



– 18 –

Implementierung innerhalb von Web-Applikationen. Zahlreiche Frameworks für Web-Anwendungen bieten Mechanismen zur Implementierung von Filtermechanismen, wie z.B. Servlet-Filter oder höher gelagerte Filter wie Struts2-Interceptors10, die eine leichte Wiederverwendbarkeit für andere Web-Applikationen ermöglichen.

4.2 Prozessmodell

Dieser Abschnitt beschreibt das Prozessmodell eines serverbasierten Comfort-Layers mit den einzelnen Schritten für das Auslesen bzw. Aktualisieren von Formularinhalten.

Abb. 4.1 zeigt das Modell eines serverbasierten Comfort-Layers.

Abb. 4.1: Modell eines serverbasierten Comfort-Layers

Unterstützt eine Web-Applikation Comfort-Layer dann wird dies dem Anwender durch ein Symbol im jeweiligen Formular angezeigt. Der Comfort-Layer fügt neben diesem Symbol bereits einen vorgefertigten XML-Request (wie in Abschnitt 6.3 spezifiziert) als versteckten HTTP(s) POST Parameter in das Formular ein. Sowohl das Befüllen von Formularfeldern als auch das Speichern von Formular-Inhalten wird vom Anwender initiiert. Dieser klickt auf einen entsprechenden Button, Link oder Symbol. Dadurch wird der vorbereitete Request an den Comfort-Layer übermittelt.

Der Comfort-Layer wertet den Request (z.B. einen ReadFormDataRequest) aus und startet

einen entsprechenden Workflow über den Browser. Der Workflow MUSS sämtliche Schritte zum Auslesen der jeweiligen Daten beinhalten (Authentifizierung, Wahl des Datenspeichers, Lesen, Entschlüsseln usw.).

10

http://struts.apache.org/2.x/docs/interceptors.html

http://struts.apache.org/2.x/docs/interceptors.html



– 19 –

Konnte die Abfrage erfolgreich abgearbeitet werden, d.h. die gewünschten Daten aus externen Repositories eingelesen bzw. in externen Repositories abgespeichert werden, dann muss der Comfort-Layer den Anwender wieder zum ursprünglichen Formular zurückführen, wobei

im Falle einer Anfrage zum Auslesen von Daten diese serverseitig bereits als Formularinhalte eingefügt werden müssen,

im Falle einer Anfrage zum Aktualisieren/Speichern von Formulardaten, der Erfolg durch einen Hinweis (z.B. als Text oder als Symbol) angezeigt werden müssen der ebenfalls serverseitig einzufügen ist,

bzw. im Falle eines Fehlers, dieser ebenfalls auf gleiche Weise angezeigt werden muss.

4.3 Zentrale Portallösung

Eine potentielles Anwendungsgebiet für einen serverseitigen Comfort-Layer bietet der österreichische Amtshelfer HELP.gv.at. Das Portal sieht sich als behördenübergreifende Plattform im Internet, die jedem Anwender Informationen über Behördenwege sowie auch jederzeit abrufbare Formulare zu speziellen Amtswegen zu Verfügung stellt.

BürgerInnen, die Verfahren online erledigen wollen, können diese Plattform verwenden um die entsprechende Web-Anwendung bzw. das entsprechende Online-Formular ihrer Gemeinde zu finden und in weiterer Folge auszufüllen.

Unter Diskussion steht die Möglichkeit, dass Antragsformulare zukünftig direkt über HELP.gv.at ausgefüllt werden können. Die Formularinhalte sollten dann transparent an die jeweiligen Gemeindeserver übertragen werden. Die BürgerIn wird dann an den Server der betreffenden Gemeinde weitergeleitet und findet schließlich ein Formular vor, dass mit den Daten aus dem Formular von HELP.gv.at vorbefüllt wurde.

Der Mehrwert einer serverseitigen Einrichtung eines Comfort-Layers auf HELP.gv.at wäre enorm da dadurch jedes über das Portal verlinktes Online-Formular indirekt den Formular-Container nutzen könnte.

http://help.gv.at/

http://help.gv.at/

http://help.gv.at/

http://help.gv.at/


Schwerpunktthema Neue Dienste Beispiele für Avatar Ausprägungen

– 20 –

5 Beispiele für Avatar Ausprägungen

In diesem Abschnitt werden zur Verdeutlichung des in diesem Dokument vorgestellten Konzepts bzw. der hier angeführten Spezifikation einige mögliche Avatar-Implementierungsvarianten angeführt.

Grundsätzlich sind beliebige Implementierungen möglich, allenfalls müssen jedoch Einschränkungen bei der Nutzung externer Repositories in Kauf genommen werden. So wird es sicherlich nicht möglich sein, einen lokalen Comfort-Layer zum Zugriff auf das ZMR zu verwenden. Gleichermaßen wird ein serverseitiger Comfort-Layer architekturbedingt nur im Zusammenspiel mit Web-Anwendungen verwendbar sein.

5.1 Avatare mit clientseitigem Comfort Layer

Avatare, die auf einem clientseitigen Comfort-Layer beruhen, sind ebenfalls clientseitige Komponenten. Da Avatare als leichtgewichtige Komponenten konzipiert sind, die ausschließlich über eine XML-Schnittstelle kommunizieren, sind deren Ausprägungsformen schier unbegrenzt.

5.1.1 Browser Avatar

Der Browser ist sicherlich das Hauptanwendungsgebiet für die Nutzung eines Comfort Layers. Auch hier gibt es – vor allem auch wegen der zahlreichen unterschiedlichen Browser – zahlreiche Möglichkeiten, Avatare zu implementieren. Am sinnvollsten erscheint sicherlich, Augenmerkt auf die populärsten Browser zu richten ([BMS2008], Stand Jänner 2008):

Internet Explorer (75,47%) Für den Internet Explorer gibt es reichlich Möglichlichkeiten, einen Avatar zu implementieren. Denkbar wären Avatare als Browser-Erweiterungen (Add-Ons11), als Browser Helper Objects12, über Window-Handles, als ActiveX-Komponente, über .NET oder auch über Windows Scripting Host denkbar.

Mozilla Firefox (16,98%) Der einfachste Weg einen Avatar unter Mozilla Firefox zu implementieren, wäre die Nutzung der Extension-Schnittstelle13.

Apple Safari (5,82%) Äquivalent zum Firefox bietet auch Safari eine entsprechende Plugin-Schnittstelle.

Andere (1,73%) Laut [BMS2008] teilen sich mindestens 16 Browser die verbleibenden 1,73% Marktanteil weshalb die Entwicklung von Avataren für einen dieser Browser nicht sinnvoll erscheint.

Am sinnvollsten erscheint die Implementierung eines Avatars mit der NPAPI-Schnittstelle (Gecko Plugin API14). Diese Schnittstelle ermöglicht die Entwicklung von Cross-Browser-Plugins für Mozilla, Firefox, Safari, Opera sowie auch für Adobe.

11

http://www.windowsmarketplace.com/category.aspx?bcatid=3500 12

Als Browser Helper Objects (BHO) werden Programme bezeichnet, die die Funktionalität des Internet Explorers (ab Version 4.0) erweitern.

13 http://developer.mozilla.org/en/docs/Extensions

14 http://developer.mozilla.org/en/docs/Gecko_Plugin_API_Reference

http://www.windowsmarketplace.com/category.aspx?bcatid=3500

http://developer.mozilla.org/en/docs/Extensions

http://developer.mozilla.org/en/docs/Gecko_Plugin_API_Reference


Schwerpunktthema Neue Dienste Beispiele für Avatar Ausprägungen

– 21 –

5.1.2 PDF Avatar

Auch wenn viele Formulare bereits online ausgefüllt werden können, gibt es immer noch eine größere Anzahl an Offline-Formularen in Form von PDF-Formularen. Unter Nutzung der Adobe Plugin-Schnittstelle könnte ein Avatar verwirklicht werden, der ein PDF-Formular genauso wie ein Online-Formular befüllt.

5.1.3 Microsoft Office Avatar

Micosoft Office bietet über den Add-In-Mechanismus ebenfalls eine Schnittstelle für Erweiterungen an. Genauso wie für PDF-Formulare wäre auch hier eine Unterstützung der Eingaben durch einen Avatar nützlich.

5.2 Avatare mit serverseitigem Comfort-Layer

Ein serverseitiger Comfort-Layer entbindet den Anwender von der Notwendigkeit, lokale Installationen (z.B. in einem Umfeld mit eingeschränkten Rechten wie einem Internet-Cafe) durchführen zu müssen. Unter dieser Voraussetzung beschränkt sich das Betätigungsfeld für Comfort-Layer auf Web-Applikationen, da nur damit komplette Authentifizierungs-Abläufe (zumindest im Zusammenhang mit der Bürgerkarte) implementiert werden können.

5.2.1 Browser Avatar

Aus Usability-Gründen sollte das Hinweis-Symbol im Browser eines serverbasierten Comfort-Layers gleich wie das im Browser eines lokal installierten Comfort-Layers aussehen. Erst der Klick auf das Symbol bzw. erst durch die danach ausgeführten Aktionen (z.B. lokale Authentifizierung mit Bürgerkarte vs. Browser-basierte Authentifikation mit Bürgerkarte) offenbaren die tatsächliche Implementierung.


Schwerpunktthema Neue Dienste Schnittstelle Comfort-Layer

– 22 –

6 Schnittstelle Comfort-Layer

Dieser Abschnitt beschreibt die Kommunikationsschnittstelle zwischen Avataren und dem Comfort-Layer. Eine einheitliche Schnittstelle auf Basis von internationalen Standards ermöglicht eine übergreifende Kommunikation zwischen verschiedenen Implementierungen und Ausprägungen von Avataren und Comfort-Layern.

Eine beliebige und universelle Kombination zwischen Avataren und Comfort-Layern ist dahingehend nicht möglich, da die Schnittstelle nicht über ein typisches Request/Response Protokoll verfügt, sondern zwischen Anfrage und Antwort auch (GUI)Interaktionen mit dem Benutzer oder anderen Komponenten erlaubt sind. Ein lokaler Avatar, der keine Interaktion mit einem Browser ermöglicht, wird bspw. nicht mit einem serverseitigen Comfort-Layer kommunizieren können, da die Interaktionsmöglichkeit über den Browser nicht unterstützt wird.

Zudem ist die Adresse, auf welcher ein serverseitiger Comfort-Layer die Schnittstelle anbietet, nicht standardisiert, und ohne die genaue Adressangabe ist die Kommunikation für einen Avatar gleichermaßen ausgeschlossen.

In den folgenden Abschnitten wird eingehender auf das Prozeß- und Kommunikationsmodell, sowie auf das Datenformat der Anfrage und Antworten für das Auslesen und Sichern von Formulardaten eingegangen.

6.1 Prozessablauf

Das folgende Modell zeigt die Relation, in welcher die beteiligten Komponenten stehen, sowie den sequentiellen Kommunikationsablauf (Nummerierung) für das Auslesen und Speichern von Formulardaten.

Abb. 6.1 Prozessablaufdiagramm

Schnittstelle (HTTP / XML)

Avatar #1

Acrobat-PDF Plugin

Avatar #2

Browser Plugin

Avatar #3

Microsoft Office Plugin

Comfort Layer

Storage Access

1

2

3



– 23 –

Ein Avatar dient ausschließlich als Komponente zur Befüllung und Sicherung von Formulardaten. Die Inhalte der auszufüllenden Formularfelder bezieht dieser über die Kommunikationsschnittstelle mit dem Comfort-Layer. Aus welcher Quelle diese Inhalte stammen, liegt im Entscheidungsbereich des Comfort-Layers bzw. des Benutzers. Der Prozessablauf zum Auslesen und Sichern von Formularinhalten ist wie folgt:

1. Der Avatar schickt einen XML Request mittels HTTP POST an dem ihm bekannten Comfort-Layer. Dieser Request kann entweder eine Anfrage zum Auslesen von bereits gespeicherten Formularinhalten sein oder eine Anfrage zum Sichern eines ausgefüllten Formulars.

2. Wo die Formularinhalte ausgelesen bzw. gesichert werden, liegt im Entscheidungsbereich des Comfort-Layers. Dieser führt die notwendigen Kommunikationsschritte mit dem Datenspeicher durch und kann auch allfällige (mehrschrittige) Interaktionen (auch GUI) mit dem Benutzer erfordern.

3. Der Comfort-Layer liefert anschließend das Resultat der Anfrage an den Avatar zurück. Dies ist im Falle des Auslesen von Formulardaten eine Liste der einzelnen Formularfelder bzw. im Falle des Sicherns von Formulardaten das Ergebnis der Operation. Auftretende Fehler in der Kommunikation mit dem Avatar oder den Datenspeichern werden über eine entsprechende Fehlermeldung in der HTTP Kommunikation oder in der XML Antwort übermittelt.

6.2 Kommunikation

Die Kommunikation zwischen Avatar und Comfort-Layer erfolgt über ein XML Protokoll, das zwischen den beiden Parteien mittels HTTP oder HTTPs POST übertragen wird. Grundsätzlich kann die Übertragung auf zwei Arten erfolgen:

1. Der XML Request wird vom Avatar direkt in einen HTTP(s) POST Request als Body eingebettet und an den Comfort-Layer geschickt.

2. Die Übertragung erfolgt mittels Verwendung von HTTP(s) POST Parametern.

Ein Comfort-Layer MUSS eine der beiden Arten unterstützen. Letztere Art der Übertragung macht vorwiegend bei serverseitigen Comfort-Layern Sinn, wohlgleich die Übertragung nach (1) bei lokal installierten Comfort-Layern primär Verwendung findet. Wird eine Übertragungsart von einem Avatar verwendet, die der Comfort-Layer nicht unterstützt, muss der Comfort-Layer die Anfrage mit einem HTTP 501 Fehler quittieren. Ein HTTP 501 Fehler zeigt an, dass der Server nicht die Funktionalität besitzt, um die Anfrage ordnungsgemäß zu beantworten.

6.2.1 Übertragung mittels HTTP(s) POST Parametern

6.2.1.1 Kodierung

Erfolgt die Übertragung der Nachricht mittels HTTP POST Parameter MUSS eine URL-Kodierung (application/x-www-form-urlencoded) von Requestparametern unterstützt werden. Die MIME Kodierung gemäß multipart/form-data KANN von einem Comfort-Layer unterstützt werden. Unterstützt ein Comfort-Layer die Kodierung gemäß MIME (multipart/form-data) nicht, MUSS ein derartiger Request mit einem HTTP 501 Fehler quittiert werden.



– 24 –

6.2.1.2 Requestparameter

Die Nachricht MUSS folgende zwei POST Parameter beinhalten:

1. XMLRequest

Dieser Parameter beinhaltet die kodierte XML Nachricht an den Comfort-Layer.

2. DataURL

Dieser Parameter beinhaltet die URL, an welche der Comfort-Layer das Ergebnis der Anfrage senden soll.

Wird bspw. eine Anfrage an den Comfort-Layer als Request in eine Website integriert, so würde ohne die Angabe der DataURL die Antwort wieder an den Browser zurückgesendet werden und der Benutzer würde die XML Antwort im Browserfenster sehen. Um dieses Verhalten zu vermeiden, MUSS die Antwort des Comfort-Layers an die angegebene DataURL gesendet werden, die den Benutzer an die entsprechende Antwortseite mit den befüllten Formulardaten weiterleitet. Somit ist eine komfortable Steuerung des Prozessablaufes garantiert.

Fehlt zumindest einer dieser Parameter, MUSS der Comfort-Layer eine entsprechende Fehlermeldung in der XML Antwort retournieren.

6.2.1.3 Weitergabeparameter

Allfällige Weitergabeparameter, die über den Comfort-Layer an das Service der DataURL weitergereicht werden sollen, MÜSSEN mit dem Zeichen „_“ enden. Der Comfort-Layer MUSS diese Parameter in der Antwort an die DataURL unverändert weitergeben. Weitergabeparameter sollen ebenfalls die komfortable Steuerung des Prozessablaufes garantieren. Eine Kommunikation mit einem serverseitigen Comfort-Layer kann als ein Sprung aus dem herkömmlichen Formularablauf betrachtet werden. Der Ausgangspunkt kann für eine erfolgreiche Rückkehr zum alten Status mit entsprechenden Weitergabeparametern markiert werden.

6.2.1.4 Weitergabeheader

Allfällige Weitergabeheader, die über den Comfort-Layer an das Service der DataURL weitergereicht werden sollen, MÜSSEN mit den Zeichen „__“ (2x Underscore) enden. Der Comfort-Layer MUSS diese Header in der Antwort an die DataURL unverändert weitergeben. Weitergabeheader sollen ebenfalls die komfortable Steuerung des Prozessablaufes garantieren.

6.2.1.5 Antwortparameter

Die XML Antwort des Comfort Layer MUSS über den Response Parameter XMLResponse

an die DataURL zurückgegeben werden.

6.3 XML Schnittstelle

Dieser Abschnitt beschreibt die XML Schnittstelle, über welche Avatare mit dem Comfort-Layer kommunizieren können. Die Schnittstelle unterstützt ausschließlich die zwei Grundoperationen zum Auslesen und Sichern von Formulardaten und arbeitet gemäß einem Request/Response Protokoll.

6.3.1 Anfrage zum Auslesen von Formulardaten



– 25 –

Abb. 6.2 ReadFormDataRequest

Das Auslesen von Formulardaten erfolgt über einen ReadFormDataRequest. Dieser

ermöglicht das Auslesen von Formularinhalten beliebiger Dokumente.

Jedes einzelne Dokument wird über eine eindeutige URI identifiziert (URI Element). Für

Webformulare ist dies beispielsweise die URL der Website, bei PDF Dateien der Speicherort (File-URI). Wird keine URI angegeben, so wird damit implizit das Auslesen eines globalen Datenspeichers für Formulardaten angefordert. Steht dieser globale Datenspeicher nicht zur Disposition, so MUSS die Antwort mit einem entsprechenden Fehler quittiert werden.

6.3.1.1 Formular

Abb. 6.3 FormType

Jedes Formular innerhalb eines bestimmten Dokuments (URI) KANN über einen eindeutigen

Bezeichner (FormId Attribut) gekennzeichnet werden. Wird diese Id nicht verwendet, z.B.

wenn das Formular im Dokument nicht mit einer solchen gekennzeichnet ist, so entsprechen die angeforderten Formulare ihrer im Dokument auftretenden Reihenfolge.

6.3.1.1.1 RequestParameter

Für das Auslesen eines Formulars KÖNNEN zusätzliche Inputparameter angegeben werden. Dies macht etwa dort Sinn, wo keine dediziert gesicherten Formularinhalte angefordert werden, sondern allgemeine Daten aus einem zentralen Verzeichnis gelesen werden sollen. Als Beispiel sei hier das Zentrale Melderegister (ZMR) genannt, wo Adressdaten über Identifikationsparameter wie Personendaten angefordert werden können. Jeder Requestparameter wird über einen Namen und den entsprechenden Wert gekennzeichnet. Im Falle des ZMRs könnten z.B. als Inputparameter der Vorname, Familienname und das Geburtsdatum dienen.



– 26 –

6.3.1.1.2 Formularfelder

Eine Anfrage erlaubt das Auslesen von dedizierten Formularfeldern, welche über das

Element FormFieldIds referenziert werden. Sind keine speziellen Formularfelder

angegeben (d.h. es fehlt das Element FormFieldIds), so MÜSSEN alle gesicherten

Formularfelder des angeforderten Formulars zurückgeliefert werden.

6.3.2 Antwort

Abb. 6.4 ReadFormDataResponse

Die Antwort zum Auslesen von Formulardaten enthält im Erfolgsfall die angeforderten

Formulardaten oder im Fehlerfall eine entsprechende ErrorResponse, welche den

Fehlercode und eine Fehlerbeschreibung beinhaltet. Für jedes angeforderte Dokument (über URI Parameter identifiziert) werden die

angeforderten Formulare des Dokuments zurückgeliefert (Forms Element). Wurde im

Request der Formularbezeichner (FormId Attribut) angegeben, so ist auch dieser in der

Antwort enthalten. Bei nicht angegebener Id werden die Formulare entsprechend der Reihenfolge des Auftretens im Dokument zurückgeliefert. Die einzelnen Formularfelder

werden über das Element FormField gekennzeichnet und enthalten den Bezeichner des

Formularfeldes (FormFieldId Element) und dessen Wert (Value Element).

6.3.3 Anfrage zum Aktualisieren bzw. Sichern von Formulardaten

Abb. 6.5 UpdateFormDataRequest



– 27 –

Die Anfrage zum Aktualisieren bzw. Sichern von Formulardaten ermöglicht das Referenzieren von beliebig vielen Dokumenten, für welche die Formulardaten aktualisiert bzw. gesichert werden sollen.

Für jedes Dokument muss der eindeutige Bezeichner angegeben werden (URI), damit

dieses im Datenspeicher eindeutig referenziert und abgelegt werden kann. Es kann pro Dokument eine beliebige Anzahl an Formularen aktualisiert bzw. gesichert

werden. Jedes Formular wird über eine eindeutige Id (FormId Attribut) gekennzeichnet. Ist

dieses Attribut nicht angegeben, so werden die Formulare gemäß der Reihenfolge des Auftretens im Dokument behandelt. Für jedes Formular kann eine beliebige Anzahl an

Formularfeldern mit dem entsprechenden Bezeichner (FormFieldId Element) und dem

dazugehörigen Wert (Value Element) angegeben werden.

6.3.4 Antwort

Abb. 6.6 UpdateFormDataResponse

Die Antwort zum Aktualisieren von Formulardaten enthält im Erfolgsfall ein Success

Element, im Fehlerfall eine entsprechende Fehlermeldung (ErrorResponse Element) mit

Fehlercode und Fehlerbeschreibung.


Schwerpunktthema Neue Dienste Infobox Datenformat

– 28 –

7 Infobox Datenformat

Dieser Abschnitt beschreibt das Datenformat für Infoboxen, welche zum (sicheren) Ablegen von Formulardaten für den Comfort-Layer verwendet werden können.

7.1 Infobox Struktur

Die Infobox, welche Formulardaten hält, muss ein assoziatives Array sein und den Namen

„FormData“ besitzen. Diese normative Einführung eines eindeutigen Bezeichners ist

dahingehend notwendig, damit beliebige Comfort-Layer mit unterschiedlichen Ausprägungen von auf dem Markt befindlichen Bürgerkartenumgebungen auf die selbe Art und Weise kommunizieren können.

7.1.1 Schlüssel

Die Subschlüssel dieses Arrays auf erster Ebene stellen die Dokumente dar, für welche Formulardaten abgespeichert werden können. Da jedes Dokument über eine eigene URI eindeutig identifizierbar ist (Website, File-URI), muss der Name eines Subschlüssel dem SHA-1 Hashwert dieser URI entsprechen. Somit können alle Dokumente mit einem eindeutigen Schlüssel identifiziert werden. Die Verwendung des SHA-1 Hashwertes dient lediglich der Komprimierung der URI, da bspw. Webseiten lange URLs besitzen können und somit in einer Überlange der Schlüssel in dem assoziativen Array resultieren würden. Der Inhalt dieser Subschlüssel muss der spezifizierten XML Datenstruktur gemäß Abschnitt 7.3 entsprechen, welche die Sammlung der (selektierten) Formularinhalte für das jeweilige Dokument beschreibt und definiert.

7.1.2 Globale Formulardaten für E-Government Formulare

Eine Bürgerkartenumgebung kann einen Subschlüssel mit dem Namen „CommonFormData“

anbieten, welcher allgemeine und oft verwendete Daten in E-Government Formularen beinhaltet. Dies können Personendaten wie Vorname, Familienname und Geburtsdatum, aber auch Adressdaten sein. Die Formularfeldbezeichner müssen den standardisierten Namen des E-Government Styleguides entsprechen (siehe [ST-DAT1.2]). Damit kann die Option geschaffen werden, dass bei Fehlen von Formulardaten in einem E-Government Formular diese aus dem

CommonFormData Container entnommen werden können. Aber auch gesicherte

Formularinhalte in E-Government oder E-Business Formularen können statt eines Wertes eine Referenz auf diese Inhalte haben, was einen zentralen Verwaltungspunkt von Personen- und Adressdaten ermöglicht. Ändert sich bspw. die Adresse, wird beim Befüllen von Formularen automatisch der Wert der globalen Infobox verwendet, falls das gesicherte Formular auf diesen Wert verweist. Das Verwenden einer globalen Infobox ist optional und ermöglicht somit diverse Anwendungsszenarien. Diese könnten bspw. sein:

1. Das Ersetzen von fehlenden Formulardaten liegt im Zuständigkeitsbereich der Bürgerkartenumgebung, d.h.

a. bei einer Anfrage wurden für ein spezielles Dokument bereits Formulardaten gespeichert, jedoch sind die Daten nicht für alle Formularfelder verfügbar. Fehlende Formularfelder könnten somit von der Bürgerkartenumgebung aus

dem CommonFormData Container entnommen werden, falls diese dort

abgelegt wurden.



– 29 –

b. bei einer Anfrage wurden für ein spezielles Dokument keine Formulardaten gespeichert. Die Daten für Formularfelder können aus dem

CommonFormData Container entnommen werden und in der Response an

den Comfort-Layer zurückgesendet werden.

2. Das Ersetzen von fehlenden Formulardaten liegt im Zuständigkeitsbereich des Comfort-Layers, d.h. das Vorgehen des Ersetzens verläuft ähnlich wie oben beschrieben, allerdings muss der Comfort-Layer bei einer Anfrage sowohl den Schlüssel mit der URI des Dokuments, für welches die Formulardaten ausgelesen

werden sollen, als auch den Schlüssel CommonFormData auslesen.

7.1.3 Beispiel

Als Beispiel werden hier zwei Webseiten anhand ihrer URLs beschrieben, welche beliebige Formulardaten beinhalten können. Website URL-1: http://demo.egiz.gv.at/ Website URL-2: http://www.bka.gv.at/

Der SHA-1 Hashwert von URL-1 ist: b3263c6acdff0bbe5943a72a7e743a36c9509aad

Der SHA-1 Hashwert von URL-2 ist: fabb49cf5cec73cac847a9704e6a0d035e3db6f9

Die Infobox-Schlüsselstruktur muss daher wie folgt aussehen:

Key für URL-1: Formdata/b3263c6acdff0bbe5943a72a7e743a36c9509aad

Key für URL-2: Formdata/fabb49cf5cec73cac847a9704e6a0d035e3db6f9

Innerhalb dieser Keys werden die Formulardaten gemäß der Spezifikation nach 7.3 gespeichert.

7.2 Verschlüsselung

Formulardaten können unverschlüsselt oder verschlüsselt in der Infobox FormData

gespeichert werden. Im Falle einer Verschlüsselung werden die Daten gemäß [XMLENC] kodiert abgelegt. Das Prozessmodell für die Entschlüsselung der Daten hängt von der Art der Implementierung des Comfort-Layers ab und kann wie folgt beschrieben werden:

7.2.1 Comfort-Layer ist eine Komponente der Bürgerkartenumgebung

Das Auslesen der Infobox FormData sowie die anschließende Entschlüsselung der Daten

kann ohne die Verwendung der Security-Layer Schnittstelle erfolgen und weist daher keinen Performanceverlust auf. Eine Ausnahme bilden dislozierte Infoboxen, die sich auf einem Infoboxserver befinden. Hier können unter Umständen durch Netzwerkkommunikation und Identifikation/Authentifizierung entsprechende Latenzzeiten entstehen.

7.2.2 Comfort-Layer ist keine Komponente der Bürgerkartenumgebung

In diesem Fall muss der Comfort-Layer über die Security-Layer Schnittstelle mit der Bürgerkartenumgebung kommunizieren. Da die Security-Layer Schnittstelle keine multiplen

Requests unterstützt, muss folglich das Auslesen der Infobox FormData und das

anschließende Entschlüsseln mit zwei sequentiell aufeinanderfolgenden Requests durchgeführt werden. Im Gegensatz zur Variante in 7.2.1 besitzt diese Variante größere Latenzzeiten und einen erheblich größeren Performanceverlust.

http://demo.egiz.gv.at/

http://www.bka.gv.at/



– 30 –

Bei der Verwendung von dislozierten Infoboxen können wie in Abschnitt 7.2.1 beschrieben weitere Latenzzeiten auftreten und die Abarbeitung der Anfrage noch zusätzlich verzögern.

7.3 XML Spezifikation

Dieser Abschnitt beschreibt das XML Datenformat, mit welchem Formularinhalte für ein

bestimmtes Dokument als Subschlüssel der Infobox FormData abgelegt werden können.

Abb. 7.1 FormDataContainer

Das Wurzelelement für die Formulardaten eines Dokuments bildet das Element

FormDataContainer. Dessen Attribut URI hält die eindeutige URI des Dokuments evident,

da der Schlüsselname aufgrund der komprimierten Form mittels SHA-1 Berechnung wenig aussagekräftig ist.

Es können beliebig viele Formulare eines Dokuments über das Element Form referenziert

und gespeichert werden. Jedes Formular kann einen eindeutigen Bezeichner (FormId

Attribut) haben. Werden keine Ids verwendet, so spiegeln die Formulare die Reihenfolge der im Dokument auftretenden Formulare wider. Der Inhalt eines Formulars – die einzelnen Formularfelder – können entweder unverschlüsselt oder in verschlüsselter Form abgespeichert werden. Auch im Falle der unverschlüsselten Form kann auf höherer Ebene durch die Bürgerkartenumgebung ein entsprechender Sicherheitsmechanismus einem gewissen Maß an Schutz Rechnung tragen. Z.B. wenn die Bürgerkartenumgebung eine passwortbasierte Verschlüsselung der Infoboxen ermöglicht.

7.3.1 Formulardaten in unverschlüsselter Form

Werden die Formulardaten in unverschlüsselter Form abgespeichert, so können die

einzelnen Formularfelder über das Element FormField mit ihrem Bezeichner

(FormFieldId) und dazugehörigen Wert (Value) eingebettet werden. An Stelle des Wertes

kann auch das Attribut Reference verwendet werden, das auf eine Formular-Id in der

globalen Infobox verweist. Ist dieses Attribut vorhanden, so MUSS der Wert aus der globalen Infobox verwendet werden.



– 31 –

7.3.2 Formulardaten in verschlüsselter Form

Der höchste Grad an Sicherheit ist de facto durch die Verschlüsselung mit der Bürgerkarte selbst gegeben. Werden die Formulardaten in verschlüsselter Form abgespeichert, so gilt für die XML Struktur dieser Daten dieselbe Abbildungsvorschrift wie für Formulardaten in unverschlüsselter Form.

Das Element CipherData enthält eine XML Struktur in verschlüsselter Form, die als

Wurzelelement das Element FormDataContent enthält. Dieses Element hat dieselbe

Funktion wie bei der unverschlüsselten Form.

7.3.3 Globale Infobox

Das Format der globalen Infobox MUSS ebenfalls dieser XML Spezifikation entsprechen, allerdings gelten folgende Einschränkungen:

1. Das URI Attribut MUSS leer sein.

2. Es DARF nur ein Form Element verwendet werden.

3. Das FormId Attribut des Form Elements MUSS leer sein.

Die Formulardaten selbst können verschlüsselt oder unverschlüsselt abgelegt werden.


Schwerpunktthema Neue Dienste Anhang

– 32 –

Anhang

Beispiele zur XML Schnittstelle

Auslesen von Formulardaten (Request)

<?xml version="1.0" encoding="UTF-8"?>

<ReadFormDataRequest xmlns="http://reference.e-government.gv.at/namespace/cl/20080201#">

<URI>http://demo.egiz.gv.at/sample/</URI>

<Forms>

<Form FormId="application">

<FormFieldIds>

<FormFieldId>VORNAME</FormFieldId>

<FormFieldId>FAMILIENNAME</FormFieldId>

<FormFieldId>AKAD_GRAD</FormFieldId>

<FormFieldId>GEBURT_DATUM</FormFieldId>

</FormFieldIds>

</Form>

</Forms>

</ReadFormDataRequest>

Auslesen von Formulardaten (Antwort)


<ReadFormDataResponse xmlns="http://reference.e-government.gv.at/namespace/cl/20080201#">


<Forms>


<FormField>


<Value>Arne</Value>

</FormField>

<FormField>


<Value>Tauber</Value>

</FormField>

<FormField>


<Value>Dipl.-Ing.</Value>

</FormField>

<FormField>


<Value>1979-08-21</Value>

</FormField>

</Form>

</Forms>

</ReadFormDataResponse>

Sichern von Formulardaten (Request)


<UpdateFormDataRequest xmlns="http://reference.e-government.gv.at/namespace/cl/20080201#">


<Forms>


<FormField>

<FormFieldId>STRASSE</FormFieldId>

<Value>Musterstraße</Value>

</FormField>

<FormField>

<FormFieldId>HAUSNUMMER</FormFieldId>

<Value>1</Value>

</FormField>

<FormField>

<FormFieldId>GEMEINDE</FormFieldId>

<Value>Graz</Value>

</FormField>

<FormField>

<FormFieldId>POSTLEITZAHL</FormFieldId>

<Value>8010</Value>

</FormField>

</Form>



– 33 –

</Forms>

</UpdateFormDataRequest>

Sichern von Formulardaten (Antwort – Erfolgsfall)


<UpdateFormDataResponse xmlns="http://reference.e-government.gv.at/namespace/cl/20080201#">

<Success/>

</UpdateFormDataResponse>

Sichern von Formulardaten (Antwort – Fehler)


<UpdateFormDataResponse xmlns="http://reference.e-government.gv.at/namespace/cl/20080201#">

<ErrorResponse>

<Code>1000</Code>

<Info>Unklassifizierter Fehler.</Info>

</ErrorResponse>

</UpdateFormDataResponse>

Beispiele zum XML Infobox Format

Unverschlüsselte Formulardaten


<FormDataContainer xmlns=http://reference.e-government.gv.at/namespace/ibcl/20080204#

URI="http://demo.egiz.gv.at/authenticate/">

<Form FormId="auth">

<FormDataContent>

<FormField>

<FormFieldId>GivenName</FormFieldId>

<Value>Arne</Value>

</FormField>

<FormField>

<FormFieldId>FamilyName</FormFieldId>


</FormField>

<FormField>

<FormFieldId>DateOfBirth</FormFieldId>


</FormField>

</FormDataContent>

</Form>

</FormDataContainer>

Unverschlüsselte Formulardaten mit Referenz auf globale Infobox


<FormDataContainer xmlns="http://reference.e-government.gv.at/namespace/ibcl/20080204#"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc=http://www.w3.org/2001/04/xmlenc#



<FormDataContent>

<FormField>

<FormFieldId>GivenName</FormFieldId>

<Value Reference="VORNAME"/>

</FormField>

<FormField>

<FormFieldId>FamilyName</FormFieldId>

<Value Reference="FAMILIENNAME"/>

</FormField>

<FormField>

<FormFieldId>DateOfBirth</FormFieldId>

<Value Reference="GEBURT_DATUM"/>

</FormField>

<FormField>

<FormFieldId>SomeOtherValueNotReferenced</FormFieldId>

<Value>X.Y.Z.</Value>

</FormField>

</FormDataContent>

</Form>


http://reference.e-government.gv.at/namespace/ibcl/20080204

http://www.w3.org/2001/04/xmlenc

– 34 –

Verschlüsselte Formulardaten



xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"



<EncryptedFormDataContent>

<ds:KeyInfo>



</ds:KeyInfo>

<xenc:CipherData>

<xenc:CipherValue>



</xenc:CipherValue>

</xenc:CipherData>

</EncryptedFormDataContent>

</Form>


Beispiel für eine globale Infobox



xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc=http://www.w3.org/2001/04/xmlenc#

URI="">

<Form FormId="">

<FormDataContent>

<FormField>



</FormField>

<FormField>


<Value>Dipl.-Ing.</Value>

</FormField>

<FormField>


<Value>Arne</Value>

</FormField>

<FormField>



</FormField>

<FormField>

<FormFieldId>STRASSE</FormFieldId>

<Value>Musterstraße</Value>

</FormField>

<FormField>

<FormFieldId>HAUSNUMMER</FormFieldId>

<Value>1</Value>

</FormField>

<FormField>

<FormFieldId>POSTLEITZAHL</FormFieldId>

<Value>8010</Value>

</FormField>

<FormField>

<FormFieldId>GEMEINDE</FormFieldId>

<Value>8010</Value>

</FormField>

</FormDataContent>

</Form>


http://www.w3.org/2001/04/xmlenc


Schwerpunktthema Neue Dienste Referenzen

– 35 –

Referenzen

[KEYWORDS] Bradner, S.: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. IETF Request For Comment, März 1997. Abgerufen aus dem World Wide Web am 20.09.2007 unter http://www.ietf.org/rfc/rfc2119.txt

[BMS2008] Net Applications: Browser Market Share for January 2008 Abgerufen aus dem World Wide Web am 05.02.2008 unter http://marketshare.hitslink.com/report.aspx?qprid=0

[ST-DAT1.2] Mittheisz, J und Wiesner H.: Standarddaten für E-Formulare öffentlicher Entwurf vom 01.06.2004, Version 1.2.0 Abgerufen aus dem World Wide Web am 07.02.2008 unter http://reference.e-government.gv.at/Q-SG_st-dat_1_2_0___1_6_2004.1190.0.html

[SECLAYER] Hollosi A., Karlinger G., Die österreichische Bürgerkarte, Applikationsschnittstelle Security-Layer. Abgerufen aus dem World Wide Web am 07.02.2008 unter http://www.buergerkarte.at/konzept/securitylayer/spezifikation/aktuell/

[XMLENC] Eastlake D., Reagle J., XML Encryption Syntax and Processing. Abgerufen aus dem World Wide Web am 07.02.2008 unter http://www.w3.org/TR/xmlenc-core/

http://www.ietf.org/rfc/rfc2119.txt

http://marketshare.hitslink.com/report.aspx?qprid=0

http://reference.e-government.gv.at/Q-SG_st-dat_1_2_0___1_6_2004.1190.0.html

http://reference.e-government.gv.at/Q-SG_st-dat_1_2_0___1_6_2004.1190.0.html

http://www.buergerkarte.at/konzept/securitylayer/spezifikation/aktuell/

http://www.w3.org/TR/xmlenc-core/

konzept und spezifikation gesicherter formularcontainer filekonzept und spezifikation gesicherter...

Documents