Logo
Errata der Spezifikationen zur österreichischen Bürgerkarte

Konvention

-
Empfehlung
Kurzbeschreibung

Das vorliegende Dokument ist eine Sammlung von bekannten Errata in den Spezifikationen zur österreichischen Bürgerkarte ab der Version 1.1.0.

Autoren:

Arno Hollosi

Gregor Karlinger

Thomas Rössler

Martin Centner

et al.
Projektteam/Arbeitsgruppe
AG Bürgerkarte
Datum:1.3.2005

Inhaltsverzeichnis

1. Einleitung
1.1. Geltung dieses Dokuments
1.2. Struktur eines Erratum-Eintrags
1.3. Kontakt für Erratum-Bericht
2. Indizes der Errata
2.1. Nach Berichtszeitpunkt
2.2. 2.2 Nach zugehörigem Spezifikationsdokument
3. Liste der Errata
3.1. Errata in "Einführung"
3.2. Errata in "Applikationsschnittstelle Security-Layer"
3.3. Errata in "Transportprotokolle Security-Layer"
3.4. Errata in "Minimale Umsetzung des Security-Layers"
3.5. Errata in "Standardisierte Key- und Infoboxen"
3.6. Errata in "Fehlercodes"
3.7. Errata in "Zugriffsschutz"
3.8. Errata in "Anforderungen an die Benutzer-Schnittstelle"
3.9. Errata in "Standard-Anzeigeformat"

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

Dieses Dokument listet die bekannten Errata in den Spezifikationen zur österreichischen Bürgerkarte ab der Version 1.1.0.

Die in diesem Dokument gelisteten Errata beziehen sich auf sämtliche Spezifikationsdokumente zur österreichischen Bürgerkarte, im Einzelnen sind das:

Mit dem Erscheinen eines der Spezifikationsdokumente mit einer höheren Versionsnummer werden die bis zu diesem Erscheinungsdatum gelisteten Errata in die aktualisierte Spezifikation eingearbeitet, sämtliche Errata bleiben jedoch in diesem Dokument weiter gelistet.

Sobald ein Erratum in dieses Dokument eingetragen wurde, gilt er - falls anwendbar - im Sinne der im Eintrag angeführten Korrektur als behoben.

Dieser Abschnitt listet die Errata nach dem Zeitpunkt ihrer Aufnahme in dieses Dokument.

  • Erratum 1 (21. 02. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 2 (21. 02. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 3 (21. 02. 2003) - Minimale Umsetzung des Security-Layers

  • Erratum 4 (21. 02. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 5 (21. 02. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 6 (21. 02. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 7 (21. 02. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 8 (05. 03. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 9 (05. 03. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 10 (05. 03. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 11 (24. 03. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 12 (24. 03. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 13 (24. 03. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 14 (24. 03. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 15 (24. 03. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 16 (24. 03. 2003) - Transportprotokolle Security-Layer

  • Erratum 17 (07. 05. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 18 (02. 09. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 19 (04. 09. 2003) - Transportprotokolle Security-Layer

  • Erratum 20 (06. 10. 2003) - Applikationsschnittstelle Security-Layer

  • Erratum 21 (29. 06. 2004) - Applikationsschnittstelle Security-Layer

  • Erratum 22 (29. 06. 2004) - Applikationsschnittstelle Security-Layer

  • Erratum 23 (30. 07. 2004) - Applikationsschnittstelle Security-Layer

  • Erratum 24 (16. 09. 2004) - Standard-Anzeigeformat

  • Erratum 25 (11. 02. 2005) - Standardisierte Key- und Infoboxen

  • Erratum 26 (11. 02. 2005) - Applikationsschnittstelle Security-Layer

  • Erratum 27 (11. 02. 2005) - Applikationsschnittstelle Security-Layer

  • Erratum 28 (11. 02. 2005) - Anforderungen an die Benutzer-Schnittstelle

  • Erratum 29 (11. 02. 2005) - Applikationsschnittstelle Security-Layer

  • Erratum 30 (01. 03. 2005) - Standard-Anzeigeformat

  • Erratum 31 (01. 03. 2005) - Transportprotokolle Security-Layer

  • Erratum 32 (01. 03. 2005) - Applikationsschnittstelle Security-Layer

Dieser Abschnitt listet die Errata nach den zugehörigen Spezifikationsdokumenten.

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 2.2.2, Implizite Transformationsparameter
 
Bericht Fehlernummer 11 behoben ab Version 1.2.0
am 24. 03. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Die Spezifikation lässt offen, was genau die Bürgerkarten-Umgebung als Eingangsdaten für die Berechnung des Hash-Wertes über einen impliziten Transformationsparameter verwenden muss. Der Abschnitt "Implizite Transformationsparameter" wird daher um folgenden Absatz ergänzt:

"Die Eingangsdaten für die Berechnung des Hash-Wertes über einen implizten Transformationsparameter ergeben sich wie folgt:

  • Wird der implizite Transformationsparameter als Referenz angegeben, die von der Bürgerkarten-Umgebung selbst aufzulösten ist, ist zwischen einer externen und einer internen Referenz zu unterscheiden:

    • Die Auflösung einer externen Referenz MUSS einen Byte-Stream liefern. Dieser Byte-Stream bildet die Eingangsdaten für die Hash-Berechnung.

    • Die Auflösung einer internen Referenz MUSS eine XPath-Knotenmenge liefern (vgl. [XMLDSIG, Abschnitt 4.3.3.3]). Diese Knotenmenge ist nach [C14N] zu kanonisieren, um einen eindeutigen Byte-Stream zu erhalten. Dieser Byte-Stream bildet dann die Eingangsdaten für die Hash-Berechnung.

  • Wird der implizite Transformationsparameter als Referenz angegeben, die von der Bürgerkarten-Umgebung nicht selbst aufzulösen ist, weil in der Anfrage ein entsprechendes Ergänzungsobjekt angegeben wurde, ist wiederum zwischen einer externen und einer internen Referenz zu unterscheiden:

    • Enthält das Ergänzungsobjekt Daten für eine externe Referenz, MÜSSEN diese Daten als Base64 (in sl10:Supplement/sl10:Content/sl10:Base64Content) vorliegen. Die Base64-dekodierten Daten bilden dann die Eingangsdaten für die Hash-Berechnung.

    • Enthält das Ergänzungsobjekt Daten für eine interne Referenz, MÜSSEN diese Daten als XML (in sl10:Supplement/sl10:Content/sl10:XMLContent) vorliegen. Aus diesen Daten ist entsprechend [XMLDSIG, Abschnitt 4.3.3.3] eine XPath-Knotenmenge zu erzeugen. Diese Knotenmenge ist nach [C14N] zu kanonisieren, um einen eindeutigen Byte-Stream zu erhalten. Dieser Byte-Stream bildet dann die Eingangsdaten für die Hash-Berechnung."

In Abschnitt 9 der Spezifikation ist weiters folgende Referenz aufzunehmen:

"C14N Boyer, John: Canonical XML. W3C Recommendation, März 2001. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/2001/REC-xml-c14n-20010315."

Ort Version 1.1.0 Auftreten im Dokument Abschnitt 3.2.2, Prüfung des Signaturmanifests
 
Bericht Fehlernummer 20 behoben ab Version 1.2.0
am 06. 10. 2003 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Editorialer Fehler
 
Beschreibung

Durch die mittels Errata 7 eingeführte Änderung kann es nun vorkommen, dass keine impliziten Transformationsparameter vorliegen, und somit eine Signatur, die dieser Spezifikation genügt, kein Signaturmanifest beinhalten muss. Die Tabelle, welche die Bedeutung der Prüfcodes festschreibt, wird daher wie folgt geändert:

sl11:Code Bedeutung
0

Dieser Code hat eine der folgenden Bedeutungen:

  • Für diese Signatur ist kein Signaturmanifest notwendig.

  • Die Signatur enthält eine Referenz auf das notwendige Signaturmanifest. Das Signaturmanifest entspricht vom Umfang her den Anforderungen dieser Spezifikation. Für jede dsig:Reference des Signaturmanifests konnte der Hash-Wert erfolgreich überprüft werden.

1Die Signatur enthält keine Referenz auf das notwendige Signaturmanifest.
2Die Signatur enthält zwar eine Referenz auf das notwendige Signaturmanifest, dieses entspricht vom Umfang her jedoch nicht den Anforderungen dieser Spezifikation. Die Hash-Werte der im Signaturmanifest vorhandenen dsig:Reference-Elemente wurden nicht überprüft.
3Die Signatur enthält eine Referenz auf das notwendige Signaturmanifest. Das Signaturmanifest entspricht vom Umfang her den Anforderungen dieser Spezifikation. Bei der überprüfung des Hash-Werts zumindest einer dsig:Reference des Signaturmanifests ist jedoch ein Fehler aufgetreten.
99Die Prüfung eines gegebenenfalls notwendigen Signaturmanifests wurde nicht durchgeführt, da bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist.

Ort Version 1.1.0 Auftreten im Dokument XML-Schema Core.20020831.xsd
 
Bericht Fehlernummer 23 behoben ab Version 1.2.0
am 30. 07. 2004 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Fehler
 
Beschreibung

Die Schema-Definitionen der Typen sl11:ReferencesCheckResultType, sl11:ReferencesCheckResultInfoType, sl11:ManifestRefsCheckResultType, sl11:ManifestRefsCheckResultInfoType sind fehlerhaft. Sie sind durch folgende Definitionen zu ersetzen:

<xsd:complexType name="ReferencesCheckResultType">
  <xsd:sequence>
    <xsd:element name="Code" type="xsd:nonNegativeInteger"/>
    <xsd:element name="Info" type="ReferencesCheckResultInfoType" minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ReferencesCheckResultInfoType" mixed="true">
  <xsd:sequence>
    <xsd:element name="FailedReference" type="xsd:positiveInteger" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ManifestRefsCheckResultType">
  <xsd:sequence>
    <xsd:element name="Code" type="xsd:nonNegativeInteger"/>
    <xsd:element name="Info" type="ManifestRefsCheckResultInfoType"/>
  </xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ManifestRefsCheckResultInfoType" mixed="true">
  <xsd:sequence>
    <xsd:element name="FailedReference" type="xsd:positiveInteger" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="ReferringSigReference" type="xsd:positiveInteger"/>
    <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

Ort Version 1.2.0 Auftreten im Dokument Abschnitt 3.3.2.2
 
Bericht Fehlernummer 31 behoben ab Version 1.2.1
am 01.03.2005 von Gregor Karlinger, IKT-Stabsstelle
 
Klassifikation Unklarheit
 
Beschreibung

Die Erläuterungen zur Kodierung der Formularfelder im HTTP-Request an den DataURL-Server sind nicht schlüssig:

  1. Es ist nicht festgelegt, dass die Kodierung immer multipart/mime sein muss. Die Erläuterungen für XMLResponse und BinaryResponse gehen jedoch davon aus.

  2. In den Erläuterungen für XMLResponse und BinaryResponse entsteht der Eindruck, dass Content-Type ein Feld von Content-Disposition sei. Tatsächlich sind beides jedoch unabhängige Header.

Es werden daher folgende Änderungen am Spezifikationstext durchgeführt:

  1. Der erste Absatz des Unterkapitels Kodierung des HTTP-Requests lautet nun wie folgt: "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:".

  2. Der zweite Satz des Unterkapitels Kodierung des HTTP-Requests, Weitergabe-Parameter wird gestrichen.

  3. Der zweite Satz des Unterkapitels Kodierung des HTTP-Requests, Formular-Parameter XMLResponse lautet nun wie folgt: "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).".

  4. Der zweite Satz des Unterkapitels Kodierung des HTTP-Requests, Formular-Parameter BinaryResponse lautet nun wie folgt: "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).".