Open Interfaces für das eGovernment

Die österreichische Bürgerkarte

Transportprotokolle Security-Layer

Dokumenteninformation

Inhalt

1. Allgemeines
1. Namenskonventionen
2. Schlüsselwörter
2. TCP/IP - Bindung
   1. Bezeichner, Parameter und Default-Adresse
   2. Ablauf
   3. Kodierung
3. HTTP - Bindung
   1. Bezeichner, Parameter und Default-Adresse
   2. Ablauf
      1. Allgemeines
         1. Terminologie
         2. Referenzierung von Formular-Parametern
      2. Formular-Parameter
      3. Schrittweiser Ablauf
      4. Kombination der Formular-Parameter
   3. Kodierung
      1. HTTP-Request
      2. HTTP-Response bzw. HTTP-Request an DataURL
         1. HTTP-Response an die Browser-Verbindung
         2. HTTP-Request an die DataURL
      3. Protokolle für DataURL und StylesheetURL
4. SSL/TLS - Bindung
   1. Bezeichner, Parameter und Default-Adresse
   2. Ablauf
   3. Kodierung
5. HTTPS - Bindung
   1. Bezeichner, Parameter und Default-Adresse
   2. Ablauf
   3. Kodierung
6. Referenzen
7. Historie

1 Allgemeines

Das Dokument Applikationsschnittstelle Security-Layer definiert die XML-Befehle, mit denen eine Applikation die Funktionalität der Bürgerkarte über die Schnittstelle Security-Layer nutzen kann. Dieses Dokument beschreibt, wie diese XML-Befehle in bestimmte Transportprotokolle eingebunden werden. Das folgende Blockbild zeigt die prinzipielle Struktur der Bürgerkarten-Umgebung. Die XML-Befehle werden über verschiedene Module an Transportprotokolle gebunden, im Bild z.B. an TCP/IP und HTTP. Die Module sorgen für die notwendige Umsetzung und Kodierung - die funktionalen Module der Bürgerkarten-Umgebung arbeiten nur mit den definierten XML-Kommandos und sind gegenüber dem Transport und den Eigenschaften des verwendeten Protokolls ignorant.

Die Adresse einer Bindung ist durch den verwendeten Internet-Socket bestimmt. Die Socket-Adresse besteht aus zwei Teilen: IP-Adresse und Portnummer. Für jede Bindung einer lokalen Bürgerkarten-Umgebung wird eine Default-IP-Adresse (bzw. DNS-Name) sowie eine Default-Portnummer spezifiziert.

Sofern Bindungen über die Art der übertragenen Daten unterschieden werden können, ist es möglich, dass Bindungen denselben Port benützen. Im Besonderen wird darauf hingewiesen, dass sich die TCP/IP-Bindung und die HTTP-Bindung eine Adresse teilen können müssen, ebenso wie die TLS- und HTTPS- Bindung (diese Anforderung ergibt sich aus den Default-Werten für die Ports). Die Internet Assigned Numbers Authority (IANA) hat für Bindungen des Security-Layer zwei Ports reserviert [port-numbers] (siehe Default-Werte in den Abschnitten 2.1, 3.1, 4.1 und 5.1).

1.1 Namenskonventionen

Zur besseren Lesbarkeit wurde in diesem Dokument auf geschlechtsneutrale Formulierungen verzichtet. Die verwendeten Formulierungen richten sich jedoch ausdrücklich an beide Geschlechter.

Folgende Namenraum-Präfixe werden in dieser Spezifikation zur Kennzeichnung der Namenräume von XML-Elementen verwendet:

1.2 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.

2 TCP/IP-Bindung

Die TCP/IP-Bindung ist eine 1:1 Umsetzung der Security-Layer-Befehle. Es wird eine übliche TCP/IP-Verbindung über einen Socket benutzt. Die XML-Befehle laut Applikationsschnittstelle Security-Layer werden ohne weitere Kodierung oder Umsetzung/Einbettung in der Verbindung übertragen.

2.1 Bezeichner, Parameter und Default-Adresse

Bezeichner und Parameter einer Bindung werden im Befehl GetProperties des Security-Layer verwendet. Diese Bindung trägt den Bezeichner TCP/IP und hat keine Parameter.

Die Default-IP-Adresse der TCP/IP-Bindung für lokale Bürgerkarten-Umgebungen ist 127.0.0.1, der Default-Port 3495.

2.2 Ablauf

1. Die Bürgerkarten-Umgebung öffnet das Service an der definierten Adresse und wartet auf eingehende Verbindungen.
2. Die Applikation öffnet eine Verbindung zur Service-Adresse.
3. Die Applikation überträgt den XML-Request.
4. Die Bürgerkarten-Umgebung arbeitet den XML-Request ab und schickt eine XML-Response.
5. Die Bürgerkarten-Umgebung schließt die Verbindung.

2.3 Kodierung

Es erfolgt keine weitere, einbettende Kodierung. Die XML-Befehle werden 1:1 in der TCP/IP-Verbindung übertragen.

3 HTTP-Bindung

Die HTTP-Bindung bietet der Applikation die Möglichkeit, über den Web-Browser des Bürgers direkt und ohne weitere aktive Komponenten (wie z.B. ein Applet) auf die Funktionen der Bürgerkarte zuzugreifen. Dazu ist eine entsprechende Einbettung des XML-Requests in einen HTTP-Request erforderlich.

3.1 Bezeichner und Parameter

Bezeichner und Parameter der Bindung werden im Befehl GetProperties des Security-Layer verwendet. Diese Bindung trägt den Bezeichner HTTP und hat keine Parameter.

Die Default-IP-Adresse der HTTP-Bindung für lokale Bürgerkarten-Umgebungen ist 127.0.0.1, der Default-Port 3495.

3.2 Ablauf

3.2.1 Allgemeines

3.2.1.1 Terminologie

Die Applikation übermittelt der Bürgerkarten-Umgebung bei der HTTP-Bindung ein HTML-Formular (vergleiche [HTML 4], Abschnitt 17.13), das eine Reihe von Formularelementen enthält. In den weiteren Ausführungen werden die Formularelemente in folgende Kategorien eingeteilt:

Formular-Parameter

Formular-Parameter sind jene Formularelemente, die zur Steuerung des Ablaufs in der Bürgerkartenumgebung angegeben werden. Es handelt sich dabei um die Elemente mit den Namen XMLRequest, RedirectURL, DataURL und StylesheetURL. Für detaillierte Informationen siehe Abschnitt 3.2.2.

Weitergabe-Parameter

Weitergabe-Parameter sind jene Formularelemente, die bei der Verwendung des Formular-Parameters DataURL von der Bürgerkarten-Umgebung an den mittels DataURL bezeichneten Server als Formularelement weitergegeben werden. Ein Formularelement wird zum Weitergabe-Parameter, wenn sein Name mit dem Zeichen _ (Unterstrich) endet. Siehe auch Abschnitt 3.3.2.2.

Weitergabe-Header

Weitergabe-Header sind jene Formularelemente, die bei der Verwendung des Formular-Parameters DataURL von der Bürgerkarten-Umgebung an den mittels DataURL bezeichneten Server als HTTP-Header weitergegeben werden. Ein Formularelement wird zum Weitergabe-Header, wenn sein Name mit der Zeichenfolge __ (doppelter Unterstrich) endet. Der Name des Weitergabe-Headers ist beliebig; der Wert des Weitergabe-Headers besteht dabei aus dem HTTP-Header-Namen, einem Doppelpunkt sowie dem HTTP-Header-Wert (also genau wie eine Header-Zeile im HTTP-Request, z.B. Header: Value. Siehe auch Abschnitt 3.3.2.2.

Sonstige Formular-Felder

Sonstige Formularfelder, sind all jene Formularelemente, die nicht unter eine der oben genannten Kategorien fallen. Sie werden von der Bürgerkarten-Umgebung grundsätzlich nicht ausgewertet, können aber von einem Security-Layer-Befehl aus referenziert werden (vergleiche Abschnitt 3.2.1.2).

3.2.1.2 Referenzieren von Formularfeldern

Im Kontext der HTTP-Bindung ist es möglich Formularelemente, die im HTTP-Request übergeben werden, vom einem Security-Layer Befehl aus zu referenzieren. Dabei können nicht nur die oben definierten Formular-Parameter referenziert werden, sondern beliebige Formularelemente (Formular-Parameter, Weitergabe-Parameter, Weitergabe-Header und sonstige Formular-Felder). Mögliche Anwendungsfälle sind das Referenzieren bei den Signaturbefehlen Create(XML|CMS)Signature und Verify(XML|CMS)Signature.

Das in einer solchen URL zu verwendende Protokoll lautet formdata. Als opaker Teil der URL ist der Name des zu referenzierenden Formularelements anzugeben. Als Auflösung der URL muss die Bürgerkarten-Umgebung den Wert des referenzierten Formularelements liefern.

Lautet die HTML-Schreibweise des Formularelements beispielsweise <input name="summary" value="Eine kurze Zusammenfassung"/>, so wird auf dieses Element mit der URL formdata:summary referenziert. Das Ergebnis der Aulösung ist der String Eine kurze Zusammenfassung.

3.2.2 Formular-Parameter

Folgende Formular-Parameter zur Steuerung des Ablaufs in der Bürgerkarten-Umgebung stehen zur Verfügung:

XMLRequest

Muss angegeben werden und enthält den Security-Layer Befehls-Request als XML-Struktur.

RedirectURL

Darf angegeben werden und dient ggf. zur asynchronen Umleitung der Applikation. Siehe Abschnitt 3.2.3.

DataURL

Darf angegeben werden und dient ggf. dazu, das Ergebnis der Befehlsbearbeitung durch die Bürgerkarten-Umgebung an einen bestimmten Server, anstatt es im HTTP-Response an die Applikation senden zu lassen. Siehe Abschnitt 3.2.3.

StylesheetURL

Darf angegeben werden, und wird ggf. von der Bürgerkarten-Umgebung verwendet, um das Ergebnis der Befehlsbearbeitung vor der Retournierung in der HTTP-Response an die Applikation zu transformieren. Siehe Abschnitt 3.2.3.

Anmerkung: Abschnitt 3.2.4 listet sinnvolle Kombinationen der Formular-Parameter RedirectURL, DataURL und StylesheetURL.

3.2.3 Schrittweiser Ablauf

1. Die Bürgerkarten-Umgebung öffnet das Service am angegebenen Port und wartet auf eingehende Verbindungen.
2. Eine Applikation setzt einen HTTP-Request zur angegebenen Adresse ab. Die so erzeugte Verbindung wird im folgenden als Browser-Verbindung bezeichnet.
3. Ist der Formular-Parameter RedirectURL angegeben worden, schickt die Bürgerkarten-Umgebung als Antwort einen HTTP-Redirect (HTTP Code: 302 oder 303) mit der in diesem Parameter angegebenen URL an die Applikation und schließt die Browser-Verbindung.
4. Die Bürgerkarten-Umgebung entnimmt den zu bearbeitenden Befehls-Request aus dem Formular-Parameter XMLRequest und bearbeitet ihn.
5. Ist der Formular-Parameter DataURL angegeben worden, schickt die Bürgerkarten-Umgebung die Befehls-Response entsprechend Kapitel 3.3.2.2 kodiert an den mittels DataURL bezeichneten Server. Die Antwort des Servers beeinflusst den Ablauf wie folgt:
1. HTTP-Code 200, Content-Type: text/xml oder text/plain oder text/html und Inhalt der HTTP-Response gleich <ok/> (in exakt dieser Schreibweise): die Verarbeitung setzt in Schritt 6 fort.
2. HTTP-Code 200, Content-Type: text/xml und Inhalt der HTTP-Response ungleich <ok/>: Die Daten werden als Befehls-Request ausgewertet und dem Formular-Parameter XMLRequest zugewiesen. Die anderen Formular-Parameter (StylesheetURL, RedirectURL und DataURL), Weitergabe-Parameter und -Header sowie die sonstigen (referenzierbaren) Formular-Felder bleiben unverändert. Die Verarbeitung setzt in Schritt 4 fort.
3. HTTP-Code 307, Content-Type: text/xml: Der Inhalt der HTTP-Response wird als Befehls-Request ausgewertet und dem Formular-Parameter XMLRequest zugewiesen. Der Inhalt des HTTP-Headers Location wird dem Formular-Parameter DataURL zugewiesen. Die anderen Formular-Parameter (StylesheetURL und RedirectURL), Weitergabe-Parameter und -Header sowie die sonstigen (referenzierbaren) Formular-Felder bleiben unverändert. Die Verarbeitung setzt in Schritt 4 fort.
4. HTTP-Code 200, Content-Type: application/x-www-form-urlencoded oder multipart/form-data: Der Inhalt der HTTP-Response wird als Sammlung von Formularelementen ausgewertet. Die bisherigen Formular-, Weitergabe-Parameter und -Header sowie die sonstigen (referenzierbaren) Formular-Felder werden verworfen. Stattdessen werden die in der HTTP-Response enthaltenen Formular-Parameter, Weitergabe-Parameter und -Header sowie die dort ggf. ebenfalls enthaltenen sonstigen (referenzierbaren) Formular-Felder verwendet. Die Verarbeitung setzt in Schritt 3 fort.
5. HTTP-Code 200, wobei die Kombination aus Content-Type und Inhalt der HTTP-Response nicht unter einen der Punkte 5a, 5b oder 5d fällt; HTTP-Code 307, wobei Content-Type nicht unter Punkt 5c fällt; HTTP-Code 301, 302, 303: Die HTTP-Response wird unverändert an die Browser-Verbindung weitergeleitet, die Browser-Verbindung wird geschlossen und die Verarbeitung beendet.
6. Andere Fälle (z.B. HTTP-Code 404): Die Bürgerkarten-Umgebung gibt über die Benutzerschnittstelle eine entsprechende Fehlermeldung aus, übermittelt diese auch an eine eventuell noch bestehende Browser-Verbindung, beendet diese und bricht die Verarbeitung ab.
6. Ist der Formular-Parameter StylesheetURL angegeben, liest die Bürgerkarten-Umgebung einen XSL-Stylesheet von der darin angegebenen Adresse und transformiert damit die Befehls-Response.
7. Ist der Formular-Parameter RedirectURL nicht angegeben, schickt die Bürgerkarten-Umgebung die (eventuell transformierte) Befehls-Response in der Browser-Verbindung und schließt die Browser-Verbindung

Eine serverbasierte Bürgerkarten-Umgebung darf in der Browserverbindung zwischen den Schritten 2 und 3 (bei Verwendung eines Redirects) bzw. zwischen den Schritten 2 und 7 (sonst) auch die Kommunikation der Benutzerschnittstelle abwickeln (und dabei z.B. auch Cookies setzen). Die Applikation darf also nicht davon ausgehen, dass als Antwort auf den gesendeten HTTP-Request unmittelbar der Redirect bzw. das Befehlsergebnis retourniert wird.

Anmerkung: Ist eine RedirectURL angegeben, wird im Schritt 3 die Browser-Verbindung beendet. Ein ggf. zu einem späteren Zeitpunkt notwendiges Senden von Daten an die Broswerverbindung (z.B. im Fall 5e) ist dann nicht mehr möglich. In diesem Fall muss die Bürgerkarten-Umgebung eine entsprechende Fehlermeldung über die Benutzerschnittstelle ausgeben.

Anmerkung: Wenn im obigen Ablauf als Bedingung formuliert ist, dass der HTTP-Header Content-Type beispielsweise gleich text/plain sein muss, bedeutet dass lediglich, dass der Media-Type grundsätzlich text/plain sein muss. Lautet der tatsächliche Wert von Content-Type etwa text/plain; charset=ISO-8859-1, ist die Bedingung ebenfalls erfüllt.

Anmerkung: Aus den Erläuterungen zu den Fällen 5b, 5c und 5d ergibt sich, dass sowohl die veränderten als auch die unverändert gebliebenen Parameter im nächsten HTTP-Response erneut an den mittels DataURL bezeichneten Server gesendet werden müssen.

Anmerkung: Eine Applikation, welche den Formular-Parameters DataURL verwendet, sollte im Allgemeinen davon ausgehen, dass eine Bürgerkarten-Umgebung kein Cookie-Management implementiert hat und daher auf den Cookie-Mechanismus von HTTP verzichten.

3.2.4 Kombination der Formular-Parameter

Aus dem in Abschnitt 3.2.3 beschriebenen Ablauf ergeben sich sinnvolle und nicht sinnvolle Kombinationen der Formular-Paramter RedirectURL, DataURL und StylesheetURL. Die folgende Tabelle gibt eine Übersicht und erläutert kurz die Auswirkungen:

3.3 Kodierung

3.3.1 HTTP-Request

Der HTTP-Request der Applikation an die Bürgerkarten-Umgebung muss entsprechend [HTTP 1.1] kodiert sein. Die Methode muss entweder GET oder POST sein, es müssen beide Varianten von der Bürgerkarten-Umgebung unterstützt werden. (Anmerkung: manche Webclients unterstützen nur eine limitierte Größe der GET Requests.) Die Kodierung kann als application/x-www-form-urlencoded oder als multipart/form-data erfolgen, beide Formate müssen von der Bürgerkarten-Umgebung unterstützt werden.

Wird der HTTP-Request an eine lokale Bürgerkarten-Umgebung gesendet, muss er an die URL /http-security-layer-request erfolgen. Andernfalls muss die Bürgerkarten-Umgebung mit einer HTTP 404 Fehlermeldung antworten. Wird der HTTP-Request hingegen an eine serverbasierte Bürgerkarten-Umgebung gesendet, darf der Diensteanbieter eine beliebige URL vorgeben.

3.3.2 HTTP-Response bzw. HTTP-Request an DataURL

3.3.2.1 HTTP-Response an die Browser-Verbindung

Identifkation der Bürgerkarten-Umgebung

Sendet die Bürgerkarten-Umgebung die Befehls-Response in der Browser-Verbindung (vgl. Abschnitt 3.3.2, Ziffer 7), muss sich die Bürgerkarten-Umgebung unter Verwendung des HTTP-Headers Server (vgl. [HTTP 1.1], Abschnitt 14.38) identifizieren. Der HTTP-Header Server muss dabei folgendem Muster entsprechen:

Server = "Server" ":" "citizen-card-environment" "/" cceVersion " " productName "/" productVersion

Es sind also zwei Produkt-Token anzugeben: Der erste drückt aus, dass es sich beim beim Server um eine Bürgerkarten-Umgebung handelt; cceVersion gibt die neueste Version der Security-Layer-Spezifikation an, welche die Bürgerkarten-Umgebung unterstützt (also etwa 1.2 für diese Version). Der zweite Produkt-Token bezeichnet den Hersteller der Bürgerkarten-Umgebung; productName und productVersion sind innerhalb der Grenzen von [HTTP 1.1] frei wählbar.

Die Bürgerkarten-Umgebung muss sich nach der selben Methode auch dann identifizieren, wenn sie in der Browser-Verbindung einen HTTP-Redirect sendet (vgl. Abschnitt 3.2.2, Ziffer 3).

Kodierung der HTTP-Response

Die Befehls-Response wird als Nutzinhalt der HTTP-Response an den Browser übermittelt (vergleiche Abschnitt 3.2.3, Fall 5a). Jedenfalls muss die Bürgerkarten-Umgebung den HTTP-Header Content-Type setzen:

• Liegt die Befehls-Response als XML-Struktur vor, muss entweder der Wert text/xml verwendet werden (wenn die Befehlsresponse laut Abschnitt 3.2.3, Schritt 6 nicht mit Hilfe eines Stylesheets transformiert wurde), oder aber jener MIME Media Type, der sich aus der angewandten Stylesheet-Transfomation ergibt.
• Liegt die Befehls-Response nicht als XML-Struktur vor (z.B. Binär-Response auf die Befehle DecryptCMS oder DecryptXML), muss der Content-Type entsprechend den binär übermittelten Daten gesetzt werden. Ist der Content-Type der binär übermittelten Daten nicht bekannt, muss der Wert application/octet-stream verwendet werden.

3.3.2.2 HTTP-Request an DataURL

Identifkation der Bürgerkarten-Umgebung

Sendet die Bürgerkarten-Umgebung eine Befehls-Response per HTTP-Request an den mittels DataURL bezeichneten Server (vgl. Abschnitt 3.2.2, Ziffer 5), muss sich die Bürgerkarten-Umgebung unter Verwendung des HTTP-Headers User-Agent (vgl. [HTTP 1.1], Abschnitt 14.43) identifizieren. Der HTTP-Header User-Agent muss dabei folgendem Muster entsprechen, wobei die im Muster verwendeten Variablen wie in Abschnitt 3.3.2.1 zu interpretieren sind:

User-Agent = "User-Agent" ":" "citizen-card-environment" "/" cceVersion " " productName "/" productVersion

Kodierung des HTTP-Requests

Der HTTP-Request an den mittels DataURL bezeichneten Server muss nach der Methode POST (vgl. [HTTP 1.1], Abschnitt 9.5) erfolgen, als multipart/form-data kodiert sein, und folgende Formularfelder enthalten:

Formular-Parameter ResponseType

Wird immer auf den Wert HTTP-Security-Layer-RESPONSE gesetzt (kann in späteren Versionen zur Unterscheidung herangezogen werden).

Formular-Parameter XMLResponse

Enthält die Befehls-Response, falls sie als XML-Struktur vorliegt. Der Header Content-Type muss für diesen Mime Part verwendet werden und ist fix mit dem Wert text/xml zu belegen (siehe auch Anmerkung 2 in Abschnitt 3.2.3).

Formular-Parameter BinaryResponse

Enthält die Befehls-Response, falls sie nicht als XML-Struktur vorliegt (z.B. Binär-Response auf die Befehle sl12:DecryptCMSRequest oder sl12:DecryptXMLRequest). Der Header Content-Type muss für diesen Mime Part verwendet werden, um den Content-Type der Binär-Response zu bezeichnen. Ist der Content-Type nicht bekannt, so muss der Feldwert mit application/octet-stream angegeben werden (siehe auch Anmerkung 2 in Abschnitt 3.2.3).

Weitergabe-Parameter

Die gegebenenfalls im HTTP-Request an die Bürgerkarten-Umgebung enthaltenen Weitergabe-Parameter (vgl. Abschnitt 3.2.1.1) werden in den HTTP-Request an den durch die DataURL bezeichneten Server unverändert übernommen.

Weitergabe-Header

Die gegebenenfalls im HTTP-Request an die Bürgerkarten-Umgebung enthaltenen Weitergabe-Header (vgl. Abschnitt 3.2.1.1) werden in den HTTP-Request an den durch die DataURL bezeichneten Server als HTTP-Header aufgenommen.

3.3.3 Protokolle für DataURL und StylesheetURL

Für Zugriffe auf die DataURL und die StylesheetURL müssen HTTP und HTTPS als Protokolle unterstützt werden.

4 SSL/TLS-Bindung

Die TLS-Bindung ist eine 1:1 Umsetzung der Security-Layer-Befehle. Es wird eine übliche TLS-Verbindung [TLS] über einen Socket benutzt. Die XML-Befehle laut Applikationsschnittstelle Security-Layer werden ohne weitere Kodierung oder Umsetzung/Einbettung in der Verbindung übertragen.

Die TLS-Bindung entspricht von Ablauf und Aufbau her der TCP/IP-Bindung, mit dem Unterschied, dass das zugrundeliegende Transportprotokoll TLS ist.

4.1 Bezeichner, Parameter und Default-Adresse

Bezeichner und Parameter einer Bindung werden im Befehl GetProperties des Security-Layer verwendet. Diese Bindung trägt den Bezeichner TLS und hat keine Parameter.

4.2 Ablauf

Der Ablauf ist analog zu jenem der TCP/IP-Bindung (vergleiche Abschnitt 2.2), mit dem Unterschied, dass im Punkt 2 beim Aufbau der Verbindung zusätzlich entsprechend TLS ein Handshake und eine Verschlüsselung des Kanales stattfindet.

4.3 Kodierung

Es erfolgt keine weitere, einbettende Kodierung. Die XML-Befehle werden 1:1 in der TLS-Verbindung übertragen.

5 HTTPS-Bindung

Die HTTPS-Bindung bietet wie die HTTP-Bindung der Applikationdie Möglichkeit direkt und ohne weitere aktive Komponenten (wie z.B. ein Applet) auf die Funktionen der Bürgerkarte zuzugreifen. Dazu ist eine entsprechende Einbettung des XML-Requests in einen HTTP-Request erforderlich.

Die HTTPS-Bindung entspricht der HTTP-Bindung mit dem Unterschied, dass das zugrundeliegende Transportprotokoll HTTPS [HTTPS] (HTTP mit TLS [TLS]) ist.

5.1 Bezeichner, Parameter und Default-Adresse

Bezeichner und Parameter einer Bindung werden im Befehl GetProperties des Security-Layer verwendet. Diese Bindung trägt den Bezeichner HTTPS und hat keine Parameter.

5.2 Ablauf

Der Ablauf ist analog zu jenem der HTTP-Bindung, mit dem Unterschied, dass im Punkt 2 beim Aufbau der Verbindung zusätzlich entsprechend TLS ein Handshake und eine Verschlüsselung des Kanals stattfindet.

5.3 Kodierung

Die Kodierung erfolgt wie in Abschnitt 3.3 für die HTTP-Bindung festgelegt, mit folgenden Ausnahmen:

• Wird der HTTPS-Request an eine lokale Bürgerkarten-Umgebung gesendet, muss er an die URL /https-security-layer-request erfolgen.
• Wird die XML-Antwort per HTTP(S)-Request an einen DataURL-Server gesendet, so muss der Formularparameter ResponseType auf den Wert HTTPS-Security-Layer-RESPONSE gesetzt werden.

6 Referenzen

HTML 4

Dave Ragget, Arnaud Le Hors und Ian Jacobs: HTML 4.01 Specification.W3C Recommendation, Dezember 1999. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.w3.org/TR/1999/REC-html401-19991224/.

HTTP 1.1

R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leech und T. Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1. IETF Request For Comment, Juni 1999. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc2616.txt.

HTTPS

E. Rescorla: HTTP over TLS: IETF Request For Comment, Mai 2000. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc2818.txt.

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 14. 05. 2004 unter http://www.ietf.org/rfc/rfc2119.txt.

TLS

T. Dierks und C. Allen: The TLS Protocol Version 1.0. IETF Request For Comment, Januar 1999. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc2246.txt.

IANA - Port numbers

Internet Assigned Numbers Authority: Port Numbers. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.iana.org/assignments/port-numbers.

7 Historie