www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria 1 Erweiterung Spezifikation Bürgerkarte Graz, am 07. Juni 2006 DI Thomas Rössler thomas.roessler@egiz.gv.at Zusammenfassung: In diesem Erweiterungsdokument zur Bürgerkarten- Spezifikation (Version 1.2.1) wird allgemein und konkret für die standardisierte Infobox Mandates (Vollmachten-Infobox) das Push-Verfahren spezifiziert. Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz
Inhalt 1 Einführung - Motivation... 3 1.1 Push-Verfahren am Beispiel elektronischer Vollmachten... 3 1.2 Zur Spezifikation... 4 2 Infobox-Auslesen im PUSH-Verfahren... 4 2.1 Implizite Anfrage... 4 2.2 Antwort... 4 2.2.1 Boxspezifische Parameter: Mandates Infobox... 5 3 Änderungen/Ergänzungen der Spezifikation... 5 3.1 Applikationsschnittstelle SecurityLayer... 6 3.2 Transportprotokolle Security-Layer... 6 3.2.1 Formular Parameter... 6 3.3 Standardisierte Key- und Infoboxen... 7 3.3.1 Infobox für GDA Token... 7 3.3.2 Push Zugriff für standardisierte Infoboxen... 7 3.4 Zugriffsschutz... 7 3.5 Anforderungen an die Benutzer-Schnittstelle... 8 3.5.1 Verwaltung von Infoboxen... 8 3.5.2 Stellvertretungsmodus (Vollmachten)... 8 3.5.3 GDA Modus... 8 3.6 Minimale Umsetzung der Applikationsschnittstelle Security-Layer zur österreichischen Bürgerkarte... 9 4 Beispiel... 11 4.1 Anfrage... 11 4.2 Antwort... 11 Referenzen... 13 Dokument-Historie... 13 2
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 1 Einführung - Motivation Motivation der Erweiterung der Bürgerkarten-Spezifikation ist es die Anwendung elektronischer Vollmachten (Stellvertretungen) aus Sicht des Bürgers als einen möglichst intuitiven Prozess zu gestalten. Entgegen dem bisherigen Konzept der Anwendung von elektronischen Vollmachten durch die Bürgerkartenumgebung (BKU), d.h. die Online-Applikation liest gezielt die anzuwendende Vollmacht bzw. den Inhalt der Mandates-Infobox der BKU aus, soll künftig die BKU durch den Bürger in einen Stellvertretungs-Modus gebracht werden können, wodurch die BKU selbstständig im Falle einer Identifikationsanfrage (Anforderung zum Auslesen der Personenbindung) die anzuwendende elektronische Vollmacht an die Applikation übermittelt. Somit wird das bisherige Pull-Verfahren, d.h. die Online-Applikation fragt explizit nach einer elektronischen Vollmacht bzw. nach dem Inhalt der Mandates-Infobox, durch ein Push-Verfahren, d.h. die BKU schickt automatisch die vom Bürger zur Anwendung ausgewählte Vollmacht parallel mit der Personenbindung mit, ersetzt. In diesem Erweiterungsdokument zur Bürgerkarten-Spezifikation wird allgemein und konkret für die standardisierte Infobox Mandates (Vollmachten-Infobox) das Push-Verfahren spezifiziert. Wichtigste Anforderung bei dieser Erweiterung ist die Abwärtskompatibilität zu bereits etablierten Schnittstellen, Modulen und Applikationen. Um unter dieser Vorgabe dennoch parallel zur Personenbindung auch Infoboxen-Inhalte retournieren zu können, wird daher ein neuer Typ Formular-Parameter eingeführt. Alte Applikationen, die diese Art der Übergabe von Infobox-Inhalten noch nicht unterstützen, können so unbeeinträchtigt weiter verwendet werden. 1.1 Push-Verfahren am Beispiel elektronischer Vollmachten Wird die BKU in den sog. Stellvertretungsmodus gebracht, so muss dem Anwender auf geeignete Weise eine Auswahlmöglichkeit der in der BKU gespeicherten Vollmachten geboten werden. Der Anwender kann so die gewünschte Vollmacht auswählen. Agiert die BKU im Stellvertretungsmodus, so werden alle Security-Layer Befehle unverändert und wie in Spezifikation 1.2.1 festgelegt abgearbeitet. Bei Infobox-Leseanfragen mit dem Infobox- Identifier IdentityLink, also beim Request zum Auslesen der Personenbindung, muss grundsätzlich die Personenbindung im definierten Parameter XMLResponse unverändert retourniert werden. Zusätzlich wird aber im Stellvertretungsmodus ein weiterer Formular-Parameter Mandates der Antwort hinzugefügt. Dieser Parameter enthält dann die vom Anwender ausgewählten elektronische Vollmacht(en). Die Antwort-Struktur des Mandates-Formular-Parameters folgt dem Schema der Antworten einer konventionellen Infobox-Leseanfrage. Somit werden die zu retournierenden Vollmachten in ein InfoboxReadResponse-Element gekleidet. Der Mandates-Formular-Parameter sieht vor, dass nicht nur eine sondern auch mehrere Vollmachten auf einmal an die Applikation übergeben werden können. Dies kann dann notwendig sein, wenn bspw. eine Kette von Vollmachten nachgewiesen werden muss, oder verschiedene Einzel-Vollmachten als Nachweis eines Stellvertretungsverhältnisses vorgezeigt werden müssen. Nachfolgend eine exemplarische Skizze einer kompletten http-response auf eine Personenbindungslese-Anfrage im Stellvertretungsmodus zur besseren Lesbarkeit werden Sonderzeichen nicht gequoted dargestellt und nur die einleitenden XML-Elemente der einzelnen Teile dargestellt; zur Lesbarkeit wurden auch Zeilenumbrüche eingefügt: 42 3
43 44 45 46 47 48 49 50 51 52 53 54 55 56 POST / HTTP/1.1 Referer: 127.0.0.1 User-Agent: citizen-card-environment/1.2 trustdeskbasic/2.5.2 Content-Type: application/x-www-form-urlencoded Host: demo.egiz.gv.at Content-Length: 7821 Connection: Keep-Alive Cache-Control: no-cache XMLResponse=<sl:InfoboxReadResponse>IDENTITYLINK</sl:InfoboxReadResponse> &ResponseType=HTTP-Security-Layer-RESPONSE &Mandates=<sl:InfoboxReadResponse><sl:BinaryFileData><sl:XMLContent><md:Mandate >EINE ELEKTRONISCHE VOLLMACHT</md:Mandate></sl:XMLContent></sl:BinaryFileData></sl:InfoboxReadRespon se> 57 58 59 60 61 62 63 64 65 66 1.2 Zur Spezifikation 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 [7] in festgelegt ist. Zur besseren Lesbarkeit wurde in diesem Dokument auf geschlechtsneutrale Formulierungen verzichtet. Die verwendeten Formulierungen richten sich jedoch ausdrücklich an beide Geschlechter. 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 2 Infobox-Auslesen im PUSH-Verfahren 2.1 Implizite Anfrage Anfragen zur Übergabe von Infobox-Inhalten via Push-Mechanismus werden implizit, dh. im Zuge einer Security-Layer Anfrage bzw. eines Befehls, im zusätzlichen PushInfobox Formular- Parameter gestellt, wie in Abschnitt 3.2.1.1 festgelegt. Mit diesem zusätzliche Formular-Parameter indiziert die anfragende Applikation, dass die in diesem Formular-Parameter aufgelisteten Infoboxen gepusht übergeben werden können. Die Übergabe von Infobox-Inhalten via Push-Mechanismus MUSS in Verbindung mit Infobox- Leseanfragen möglich sein. Die Erforderlichkeit der Umsetzung bei anderen Security-Layer Befehlen wird in Abschnitt 3.6 definiert. 2.2 Antwort Infobox-Inhalte DÜRFEN NICHT im Push-Verfahren übermittelt werden, wenn zuvor nicht die implizite Anfrage mittels PushInfobox Formular-Parameter gestellt wurde. Es DÜRFEN auch nur jene Infoboxen derart ausgelesen werden, deren Bezeichner als Wert im PushInfobox Formular- Parameter enthalten ist. Ob letztlich die implizite Anfrage zur Übergabe von Infobox-Inhalten via Push-Mechanismus beantwortet werden soll, obliegt den Vorgaben und der Entscheidung des Benutzers. 4
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 Der Benutzer SOLL die Möglichkeit haben, durch eine entsprechende Infobox-Verwaltung, die Übergabe von einzelnen Infoboxen via Push-Verfahren im Vorhinein zu aktivieren bzw. zu deaktivieren (siehe dazu Abschnitt 3.5.1). Bei der standardisierten Infobox Mandates MUSS standardmäßig das Auslesen im Push-Verfahren aktivierbar sein. Durch das Aktivieren des Auslesen der Infobox Mandates via Push-Mechanismus wird die Bürgerkartenumgebung in einen Stellvertretungsmodus gebracht, der dem Benutzer entsprechend erkenntlich gemacht werden MUSS siehe auch 3.5.2. Lässt der Benutzer das Auslesen der betreffenden Infobox via Push-Mechanismus zu z.b. Infobox Mandates im Stellvertretungsmodus so sendet die Bürgerkartenumgebung eine entsprechende Infobox-Leseantwort gem. Abschnitt 3.2.1.2 bzw. [1] zurück, bzw. an eine allfällige durch den DataURL Formular-Parameter angegebene Applikation. Die Mandates Infobox ist als Associative-Array definiert. Demnach sind mehrere Einträge in der Infobox möglich. Dem Benutzer MUSS daher einen oder auch mehrere Einträge des Associative- Arrays der Mandates-Infobox auswählen können (siehe dazu Abschnitt 3.5.2). Werden mehrere Einträge ausgewählt, so MÜSSEN diese in einem einzigen InfoboxReadResponse-Element zusammengefasst retourniert werden. Verweigert der Benutzer das Auslesen der Infobox bzw. ist die angeforderte Infobox nicht vorhanden, so DARF NICHT mit einer Fehlerantwort geantwortet werden. In diesem Fall bleibt die implizite Leseanfrage unbeantwortet; dh. es wird kein Antwort Formular-Parameter wie in Abschnitt 3.2.1.2 spezifiziert retourniert. 2.2.1 Boxspezifische Parameter: Mandates-Infobox Beim Auslesen von Infobox-Inhalte gelten grundsätzlich die selben Zugriffsschutzmechanismen, wie bei konventionellen Infobox-Leseanfragen (siehe auch Abschnitt 3.4). Wird die Mandates-Infobox parallel zum Personenbindung (IdentityLink Infobox) über Push- Verfahren ausgelesen, so MÜSSEN die in der Leseanfrage für die Personenbindung ggf. angegebenen boxspezifischen Parameter auch auf den Inhalt der Mandates-Infobox angewandt werden. Konkret sind im Inhalt der Mandates-Infobox die Vorkommen der Stammzahlen durch (wirtschafts-) bereichsspezifische Personenkennzeichen zu ersetzen, falls dies durch den boxspezifischen Parameter in der parallel auszuführenden Personenbindungs-Leseanfrage verlangt wird. Es gelten hier die Vorgaben für boxspezifische Parameter aus [3]. 116 117 118 119 120 121 122 123 3 Änderungen/Ergänzungen der Spezifikation Um dieses Push-Verfahren umsetzen zu können, wird die Spezifikation der Bürgerkarte in einigen Teilen erweitert bzw. modifiziert. Die nachfolgenden Abschnitte beschreiben die Änderungen im Detail. Dabei ist der Name des Abschnitts Synonym für das betreffende Kapitel der bestehenden Bürgerkarten-Spezifikation. Alle übrigen Elemente der Spezifikation, auf die in diesem Dokument nicht explizit eingegangen wird, bleiben unverändert. 124 5
125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 3.1 Applikationsschnittstelle SecurityLayer In diesem Abschnitt werden Änderungen bzgl. dem Befehlssyntax der Applikationsschnittstelle Security-Layer angegebenen. Dieses Kapitel bezieht sich somit auf den Teil Die Applikationsschnittstelle Security-Layer zur österreichischen Bürgerkarte Version 1.2.1 [1] der Bürgerkarten-Spezifikation. Hier sind keine Änderungen erforderlich. 3.2 Transportprotokolle Security-Layer In diesem Abschnitt werden Änderungen bzgl. der Transportprotokolle des Security-Layer angegebenen. Dieses Kapitel bezieht sich somit auf den Teil Transportprotokolle für die Applikationsschnittstelle Security-Layer der österreichischen Bürgerkarte Version 1.2.1 [2] der Bürgerkarten-Spezifikation. Das Push-Verfahren ist nur für HTTP-basierten Transportbindungen der Bürgerkartenumgebung dh. HTTP und HTTPS definiert. 3.2.1 Formular-Parameter Die in 3.2.2 [1] definierten Formular Parameter sind wie folgt zu erweitern: Neben den standardisierten Formular-Parametern XMLRequest, RedirectURL, DataURL und StylesheetURL können auch die in 3.2.1.1 und 3.2.1.2 definierten Formular Parameter zum Einsatz kommen. 3.2.1.1 PushInfobox Formular-Parameter Dieser Formular-Parameter DARF zusätzlich im Zuge einer Security-Layer Anfrage angegeben werden. Damit signalisiert die anfragende Applikation, dass die Inhalte der in diesem Formular- Parameter bezeichneten Infoboxen via Push-Mechanismus akzeptiert und verarbeiten werden können. Dieser Formular-Parameter enthält eine Komma-separierte Liste von Infobox-Bezeichnern oder zumindest einen Infobox-Bezeichner. Zum Beispiel: PushInfobox=Mandates,EHSPToken Das Mitgeben dieses Parameters DARF NICHT einem Infobox-Leserequest gleichgesetzt werden und automatisch zur Übergabe der gewünschten Infobox-Inhalte führen. Die Übergabe von Infobox durch den Push-Mechanismus MUSS vom Benutzer gewünscht und entsprechend voreingestellt werden. 3.2.1.2 Formular-Parameter zur Übergabe von Infoboxen via Push-Verfahren Zur Übergabe von Infobox-Inhalten via Push-Mechanismus MÜSSEN Formular-Parameter verwendet werden, deren Name dem Bezeichner der betreffenden Infobox entspricht. Einer oder mehrere <Infobox-Bezeichner>-Formular-Parameter DÜRFEN einer Security-Layer Antwort mitgegeben werden; der Name der Formular-Parameter entspricht den Bezeichnern der Infoboxen deren Inhalte jeweils als Wert im jeweiligen Formular-Parameter übergeben wird. Zum Beispiel: Mandates=<sl:InfoboxReadResponse> </sl:infoboxreadresponse> 6
164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 In diesem Formular-Parameter SOLLEN die Inhalte von Infoboxen via Push-Mechanismus übermittelt werden. Es DÜRFEN mehrere Formular-Parameter dieses Typs in einer Security-Layer Antwort mit übergeben werden. Infobox-Inhalte DÜRFEN nur dann in einem Formular-Parameter dieses Typs der Security-Layer Antwort angehängt werden, wenn mit der zugehörigen Security-Layer Anfrage der PushInfobox- Parameter mitgegeben wurde, und darin der entsprechende Infobox-Bezeichner explizit enthalten ist. Die in diesem Formular-Parameter übermittelten Infobox-Inhalte MÜSSEN der in 7.5.2 [1] definierten Antwort konventioneller Infobox-Leseanfragen entsprechen. Ist ein Infobox-Bezeichner identisch einem in Abschnitt 3.2.1 definierten Formular-Parameter, so würde das Auslesen derartiger Infoboxen im Push-Verfahren zu einem Konflikt führen. Die in Abschnitt 3.2.1 definierten Bezeichner für Formular-Parameter sind reserviert. Infoboxen mit identischen Bezeichnern DÜRFEN NICHT im Push-Verfahren ausgelesen werden können. Dies MUSS durch die Bürgerkartenumgebung verhindert werden. 3.3 Standardisierte Key- und Infoboxen In diesem Abschnitt werden Änderungen bzgl. der standardisierten Key- und Infoboxen angegebenen. Dieses Kapitel bezieht sich somit auf den Teil Standardisierte Key- und Infoboxen der österreichischen Bürgerkarte Version 1.2.1 [3] der Bürgerkarten-Spezifikation. 3.3.1 Infobox für GDA-Token In einem gesonderten Spezifikationsdokument wird die im Sinne des Gesundheitstelematikgesetzes für Gesundheitsdiensteanbieter relevante standardisierte Infobox für sog. GDA-Token definiert. Dieses Dokument wird künftig an dieser Stelle referenziert. Hier sei soweit nur die Existenz dieser zusätzlichen Infobox angemerkt. 3.3.1.1 Bezeichner Diese Infobox trägt den Bezeichner EHSPToken. Dieser Bezeichner wird von der Applikation zur Selektion der Infobox bei Lese- und Update-Zugriffen verwendet. 3.3.1.2 Typ der Infobox Diese Infobox hat den Typ Assoziatives Array. Für die damit verbundenen möglichen Lese- und Update-Zugriffe siehe Applikationsschnittstelle Security-Layer [1], Abschnitt 7. 3.3.2 Push-Zugriff für standardisierte Infoboxen Der Push-Zugriff MUSS auf folgende standardisierte Infoboxen zugelassen werden: - Mandates - EHSPToken 197 198 199 200 201 3.4 Zugriffsschutz In diesem Abschnitt werden Änderungen bzgl. dem Zugriffsschutz auf Funktionen der Bürgerkarten- Umgebung angegebenen. Dieses Kapitel bezieht sich somit auf den Teil Zugriffsschutz auf Funktionen der Bürgerkarten-Umgebung Version 1.2.1 [5][3] der Bürgerkarten-Spezifikation. 7
202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 Der Lese-Zugriff auf Infoboxen via Push-Mechanismus ist analog dem konventionellen Lesezugriff auf die betreffenden Infoboxen; es sind die selben Zugriffsschutzregeln und mechanismen anzuwenden. 3.5 Anforderungen an die Benutzer-Schnittstelle In diesem Abschnitt werden Änderungen bzgl. der Anforderungen an die Benutzer-Schnittstelle angegebenen. Dieses Kapitel bezieht sich somit auf den Teil Anforderungen an die Benutzer- Schnittstelle Version 1.2.0 [5][3] der Bürgerkarten-Spezifikation. 3.5.1 Verwaltung von Infoboxen Das User-Interface zur Verwaltung von Infoboxen SOLL die Möglichkeit geben, bei den vorhanden Infoboxen das Auslesen via Push-Mechanismus einzeln aktivieren oder deaktivieren zu können. Bei den standardisierten Infoboxen Mandates und EHSPToken MUSS das Auslesen von Infoboxen via Push-Mechanismus aktivierbar sein. Siehe auch Abschnitt 3.5.2. und 3.5.3. 3.5.2 Stellvertretungsmodus (Vollmachten) Aktiviert der Benutzer das Auslesen der Infobox Mandates im Push-Verfahren, wird die Bürgerkartenumgebung im sog. Stellvertretungsmodus betrieben. Dieser Umstand MUSS dem Benutzer durch die Bürgerkartenumgebung entsprechend visualisiert werden. Die Bürgerkartenumgebung SOLL ein entsprechendes, vom Normalbetrieb deutlich abweichendes Symbol präsentieren (bspw. durch ein deutliches Symbol in der Task-Leiste des Betriebssystems, etc.). Aktiviert der Benutzer den Stellvertretungsmodus, so MUSS dem Benutzer eine Auswahlmöglichkeit präsentiert werden, durch den er die im Push-Verfahren zu übermittelnden Einträge der Mandates- Infobox auswählen kann. Der Benutzer MUSS eine oder auch mehrere Einträge des Associative-Arrays der Mandates- Infobox auswählen können. Werden mehrere Einträge ausgewählt, so MÜSSEN diese in einem InfoboxReadResponse-Element zusammengefasst retourniert werden. Ist aufgrund des festgelegten Zugriffsschutzes bei Zugriffen auf die Mandates-Infobox zusätzlich noch eine Benutzerinteraktion erforderlich (Aktionsklasse Info oder Confirm), so muss diese ungeachtet des Stellvertretungsmodus verlangt werden. 3.5.3 GDA-Modus Aktiviert der Benutzer das Auslesen der Infobox EHSPToken im Push-Verfahren, so wird die Bürgerkartenumgebung im sog. GDA-Modus betrieben. Dieser Umstand MUSS dem Benutzer durch die Bürgerkartenumgebung entsprechend visualisiert werden. Die Bürgerkartenumgebung SOLL ein entsprechendes, vom Normalbetrieb deutlich abweichendes, eindeutiges Symbol präsentieren (bspw. durch ein deutliches Symbol in der Task-Leiste des Betriebssystems, etc.). Aktiviert der Benutzer den GDA-Modus, so MUSS dem Benutzer eine Auswahlmöglichkeit präsentiert werden, durch den er die im Push-Verfahren zu übermittelnden Einträge der EHSPToken-Infobox auswählen kann. Der Benutzer MUSS eine oder auch mehrere Einträge des Associative-Arrays der EHSPToken- Infobox auswählen können. Werden mehrere Einträge ausgewählt, so MÜSSEN diese in einem InfoboxReadResponse-Element zusammengefasst retourniert werden. 8
242 243 244 245 246 247 248 249 250 251 252 253 254 Ist aufgrund des festgelegten Zugriffsschutzes bei Zugriffen auf die EHSPToken-Infobox zusätzlich noch eine Benutzerinteraktion erforderlich (Aktionsklasse Info oder Confirm), so muss diese ungeachtet des GDA-Modus verlangt werden. 3.6 Minimale Umsetzung der Applikationsschnittstelle Security-Layer zur österreichischen Bürgerkarte In diesem Abschnitt werden Änderungen bzgl. der Anforderungen an die Minimale Umsetzung der Applikationsschnittstelle Security-Layer zur österreichischen Bürgerkarte angegebenen. Dieses Kapitel bezieht sich somit auf den Teil Minimale Umsetzung der Applikationsschnittstelle Security- Layer zur österreichischen Bürgerkarte Version 1.2.0 [6][3] der Bürgerkarten-Spezifikation. Das Push-Verfahren MUSS in Verbindung mit Infobox-Leseanfragen möglich sein. Bei anderen Security-Layer Befehlen DARF das Push-Verfahren unterstützt werden. Nachfolgende Tabelle gibt die Erforderlichkeit der Umsetzung des Push-Verfahrens für jeden Security-Layer Befehl an: 255 Signaturbefehl Kommandonamen Umsetzung Push-Verfahren Signatur nach CMS erstellen sl:createcmssignaturerequest sl:createcmssigantureresponse EMPFOHLEN Signatur nach XMLDSIG erstellen Signatur nach CMS prüfen Signatur nach XMLDSIG prüfen Verschlüsselung als CMS- Nachricht Verschlüsselung als XML- Nachricht Entschlüsselung einer CMS- Nachricht Entschlüsselung einer XML- Nachricht Hashwert-Berechnung sl:createxmlsignaturerequest sl:createxmlsignatureresponse sl:verifycmssignaturerequest sl:verifycmssignatureresponse sl:verifyxmlsignaturerequest sl:verifyxmlsignatureresponse sl:encryptcmsrequest sl:encryptcmsresponse sl:encryptxmlrequest sl:encryptxmlresponse sl:decryptcmsrequest sl:decryptcmsresponse sl:decryptxmlrequest sl:decryptxmlresponse sl:createhashrequest sl:createhashresponse EMPFOHLEN 9
Hashwert-Verifikation Abfrage verfügbarer Infoboxen Anlegen einer Infobox Löschen einer Infobox Lesen von Infobox-Daten Verändern von Infobox-Daten Null-Operation Abfrage der Umgebungseigenschaften Abfrage des Tokenstatus sl:verifyhashrequest sl:verifyhashresponse sl:infoboxavailablerequest sl:infoboxavailableresponse sl:infoboxcreaterequest sl:infoboxcreateresponse sl:infoboxdeleterequest sl:infoboxdeleteresponse sl:infoboxreadrequest sl:infoboxreadresponse sl:infoboxupdaterequest sl:infoboxupdateresponse sl:nulloperationrequest sl:nulloperationresponse sl:getpropertiesrequest sl:getpropertiesresponse sl:getstatusrequest sl:getstatusresponse ERFORDERLICH 256 257 10
258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 4 Beispiel Nachfolgendes Beispiel auf Basis http-protokoll zeigt die implizite Anfrage und die darauf folgende Antwort im Push-Verfahren bei elektronischen Vollmachten. Zur besseren Lesbarkeit wurden Zeilenumbrüche eingefügt; Infobox-Inhalte werden abgekürzt dargestellt. 4.1 Anfrage Infobox-Leseanfrage (Infobox-Identifier: IdentityLink) mit PushInfobox-Formular-Parameter. POST /http-security-layer-request HTTP/1.1 Accept: */* Accept-Language: de-at Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 Host: 127.0.0.1 Content-Length: 335 Connection: Keep-Alive Cache-Control: no-cache XMLRequest=%3CInfoboxReadRequest+xmlns%3D%22http%3A%2F%2Fwww.buergerka rte.at%2fnamespaces%2fsecuritylayer%2f20020225%23%22%3e%0d%0a%3cinfoboxi dentifier%3eidentitylink%3c%2finfoboxidentifier%3e%0d%0a%3cbinaryfileparameter s+contentisxmlentity%3d%22true%22%2f%3e%0d%0a%3c%2finfoboxreadreques t%3e%0d%0a &DataURL=https://demo.egiz.gv.at &PushInfobox=Mandates 4.2 Antwort Antwort hier im Beispiel als POST-Request an die in der Security-Layer Anfrage angegebene DataURL mit der Personenbindung als Antwort auf die Personenbindungs-Leseanfrage und dem zusätzliche Mandate-Formular-Parameter mit dem Inhalt der Mandates-Infobox. POST / HTTP/1.1 User-Agent: citizen-card-environment/1.2 trustdeskbasic/2.5.2 Content-Type: application/x-www-form-urlencoded Host: demo.egiz.gv.at Content-Length: 7821 Connection: Keep-Alive Cache-Control: no-cache XMLResponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF- 8%22%3F%3E%3Csl10%3AInfoboxReadResponse+xmlns%3Asl10%3D%22http%3A%2F %2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylayer%2F20020225%23%22%3E%3 Csl10%3ABinaryFileData%3E%3Csl10%3AXMLContent%3E%3Csaml%3AAssertion+ PERSONENBINDUNG (INHALT IDENTITYLINK-INFOBOX) %3C%2Fsaml%3AAssertion%3E%3C%2Fsl10%3AXMLContent%3E%3C%2Fsl10%3ABinar yfiledata%3e%3c%2fsl10%3ainfoboxreadresponse%3e &ResponseType=HTTP-Security-Layer-RESPONSE 11
305 306 307 308 309 310 311 312 &Mandates=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF- 8%22%3F%3E%3Csl10%3AInfoboxReadResponse+xmlns%3Asl10%3D%22http%3A%2F %2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylayer%2F20020225%23%22%3E%3 Csl10%3ABinaryFileData%3E%3Csl10%3AXMLContent%3E%3Cmd%3AMandate+ EINE ODER MEHRERE ELEKTRONISCHE VOLLMACHT(EN) %3C%2Fmd%3AMandate%3E%3C%2Fsl10%3AXMLContent%3E%3C%2Fsl10%3ABinary FileData%3E%3C%2Fsl10%3AInfoboxReadResponse%3E 313 12
314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 Referenzen [1] Stabsstelle IKT-Strategie: Die Applikationsschnittstelle Security-Layer zur österreichischen Bürgerkarte Version 1.2.2; 1.März 2005. [2] Stabsstelle IKT-Strategie: Transportprotokolle für die Applikationsschnittstelle Security-Layer der österreichischen Bürgerkarte Version 1.2.1; 1.März 2005. [3] Stabsstelle IKT-Strategie: Standardisierte Key- und Infoboxen der österreichischen Bürgerkarte Version 1.2.1; 1.März 2005. [4] Stabsstelle IKT-Strategie: Zugriffsschutz auf Funktionen der Bürgerkarten-Umgebung Version 1.2.1; 1. März 2005. [5] Stabsstelle IKT-Strategie: Anforderungen an die Benutzer-Schnittstelle zur Bürgerkarten- Umgebung der österreichischen Bürgerkarte Version 1.2.0; 14. April 2004. [6] Stabsstelle IKT-Strategie: Minimale Umsetzung der Applikationsschnittstelle Security-Layer zur österreichischen Bürgerkarte Version 1.2.0; 14. Mai 2004. [7] 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 14. 05. 2004 unter http://www.ietf.org/rfc/rfc2119.txt. 331 332 333 Dokument-Historie Version: Autor: 1.0.0 Datum: 2006-06-02 Kommentar: - erstellt. DI Thomas Rössler, EGIZ 334 335 13