Standard-Anzeigeformat zur Bürgerkarten-Umgebung der
österreichischen Bürgerkarte | Konvention | |
1.2.1 | ||
Empfehlung | ||
Kurzbeschreibung | Dieses Dokument spezifiziert das Standard-Anzeigeformat zur österreichischen Bürgerkarte, basierend auf XHTML 1.1 und CSS 2. Das Standard-Anzeigeformat muss von jeder Bürgerkarten-Umgebung verarbeitet und zur Anzeige gebracht werden können. | |
Autoren: | et al. | Projektteam/Arbeitsgruppe |
AG Bürgerkarte | ||
Datum: | 1.3.2005 |
Damit eine Anwendung Kommandos der Schnittstelle Security-Layer verwenden kann, ohne die konkrete Implementierung dahinter (Bürgerkarten-Umgebung) kennen zu müssen, ist es nicht zuletzt erforderlich, dass es zumindest ein Anzeigeformat gibt, dass von jeder Bürgerkarten-Umgebung verarbeitet und zur Anzeige gebracht werden kann.
Dieses Dokument spezifiziert dieses Standard-Anzeigeformat. Die Basis dafür bilden die internationalen Standards [XHTML 1.1] und Cascading Stylesheets 2 [CSS 2]. Ausgehend von dieser Basis werden Einschränkungen definiert, damit sich das Anzeigeformat für eine sichere Anzeige eignet. Beispielsweise werden Link-Informationen oder dynamische Elemente wie Scripts nicht zugelassen.
Abschnitt 2, „Profil von XHMTL 1.1“ definiert das Profil von [XHTML 1.1]. Mit diesem Profil ist die grundsätzliche Struktur eines dem Standard-Anzeigeformat entsprechenden Dokuments festgelegt.
Abschnitt 3, „Profil von CSS 2“ definiert das Profil von [CSS
2], mit dem es möglich ist, die Layout-Information für ein dem
Standard-Anzeigeformat endsprechendes Dokument festzulegen. Die Einbindung
der CSS-Informationen in die XHTML-Struktur des Dokuments erfolgt
ausschließlich über das Element <xhtml:style>
.
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:
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.
Insbesondere sei an dieser Stelle auf die schwerwiegend unterschiedliche Bedeutung von SOLLTE (bzw. dessen Entsprechungen) im Gegensatz zu DARF (bzw. dessen Entsprechungen) hingewiesen (vgl. [Keywords], Abschnitte 3 und 5).
Ein Dokument, das den Festlegungen dieser Spezifikation genügt, oder von dem angenommen wird, dass es den Festlegungen dieser Spezifikation genügt.
Diese Phrase bedeutet, dass ein Instanzdokument von der Anzeigekomponente der Bürgerkarten-Umgebung NICHT zur Anzeige gebracht werden DARF. Die Bürgerkarten-Umgebung MUSS in einem solchen Fall einen Fehler an den Aufrufer signalisieren.
Diese Phrase bedeutet, dass ein bestimmter Teil aus dem Instanzdokument (z.B. ein Attributwert oder der Inhalt eines Elements) von der Anzeigekomponente der Bürgerkarten-Umgebung NICHT angezeigt werden DARF. Dies bedeutet aber nicht, dass das Instanzdokument deswegen von der Bürgerkarten-Umgebung zurückgewiesen werden muss.
Dieser Abschnitt beschreibt das Profil für die XML-Struktur des Standard-Anzeigeformats. Der Aufbau dieses Abschnitts orientiert sich an den in [XHTML 1.1], Abschnitt 5 definierten Modulen: Für jedes Modul werden die Einschränkungen hinsichtlich der im Standard-Anzeigeformat erlaubten Elemente und Attribute angegeben.
Die zum Abschluß dieses Abschnitts referenzierten XML-Schemata dienen als normative Zusammenfassung der Einschränkungen. Sie orientiert sich an dem in [XHTML MOD] vorgeschlagenen Mechanismus zur Erstellung eines XHTML-Dialekts. Instanzdokumente, die nicht extakt diesem Schema entsprechen, müssen von einer Bürgerkarten-Umgebung zurückgewiesen werden.
Vergleiche [XHTML 1.1], Abschnitt 5.1.
Aus der Attributsammlung Core
wird das Attribut
title
gestrichen. Die Attributsammlungen
Events
, Style
und I18N
werden
zur Gänze entleert. Die Attributsammlung Common
ist damit
ident mit Core
.
Vergleiche [XHTML 1.1], Abschnitt 5.2.
Das Attribut profile
zum Element
head
wird gestrichen. Das Inhaltsmodell des Elements
head
wird auf (title, style)
verändert.
Das Attribut version
zum Element
html
wird auf den Wert
-//www.buergerkarte.at//DOCUMENT SLXHTML 1.2//DE
fixiert.
Die Elemente body
und title
bleiben
sowohl hinsichtlich Inhaltsmodell als auch hinsichtlich der
Attribute unverändert.
Das Attribut cite
zum Element
blockquote
wird gestrichen.
Die Elemente br
, cite
,
code
, div
, em
,
h1
, h2
, h3
, h4
,
h5
, h6
, p
, pre
,
span
und strong
bleiben sowohl
hinsichtlich Inhaltsmodell als auch hinsichtlich der Attribute
unverändert.
Die Content Sets Heading
und Flow
bleiben unverändert; der Content Set Block
ändert sich
zu (blockquote|div|p|pre)
; der Content Set
Inline
ändert sich zu
(br|cite|code|em|span|strong)
. Damit werden die
Elemente abbr
, acronym
,
address
, dnf
, kbd
,
q
, samp
und var
nicht
verwendet.
Das Element hr
bleibet sowohl hinsichtlich
Inhaltsmodell als auch hinsichtlich der Attribute unverändert. Die
Elemente tt
, i
, b
,
big
, small
, sup
,
sub
werden nicht verwendet.
Der Content Set Block
wird somit um das Element
hr
erweitert.
Das Inhaltsmodell bleibt für alle Elemente unverändert.
Die Attribute summary
, width
,
border
, cellpadding
,
cellspacing
, datapagesize
sowie die
Attributgruppen frame
und rules
zum
Element table
werden gestrichen.
Die Attribute abbr
, axis
,
headers
, sowie die Attributgruppen scope
,
CellHAlign
und CellVAlign
zu den Elementen
th
und td
werden gestrichen.
Die Attributgruppen CellHAlign
und
CellVAlign
zu den Elementen tr
,
thead
, tfoot
und tbody
werden
gestrichen.
Die Attribute span
und width
sowie
die Attributgruppen CellHAlign
und
CellVAlign
zu den Elementen col
und
colgroup
werden gestrichen.
Mit den Attributen colspan
und
rowspan
zu den Elementen th
und
td
ist es möglich, überlappende Tabellenbereiche zu
erzeugen. Enthält ein Instanzdokument eine Tabelle mit einem solchen
überlappenden Bereich, MUSS das
Instanzdokument von der Anzeigekomponente zurückwiesen
werden.
Die Attribute longdesc
, height
und
width
zum Element img werden gestrichen. Das
Inhaltsmodell für das Element img
bleibt
unverändert.
Referenziert ein Instanzdokument mittels des Elements
img
ein oder mehrere Bilder, so
MUSS die Bürgerkarten-Umgebung
im Fall der Signaturerstellung für jedes Bild eine der beiden
folgenden Möglichkeiten wählen:
Die Bürgerkarten-Umgebung zeigt das referenzierte Bild als Teil des Instanzdokuments an und inkludiert eine Referenz auf das Bild entsprechend der Methode in Abschnitt 4, „Bilder im Standard-Anzeigeformat“ in die Signatur.
Die Bürgerkarten-Umgebung
zeigt nicht das referenzierte Bild als Teil des Instanzdokuments
an, sondern stattdessen den Text des Attributs alt
.
In diesem Fall wird die entsprechende Bildreferenz jedoch nicht in
die Signatur inkludiert.
Anmerkung: Die zweite Variante kann von der Bürgerkarten-Umgebung gewählt werden, wenn sie das referenzierte Bild nicht auflösen kann (z.B. Broken Link), oder aber wenn die Darstellung von Bildern im Darstellungskontext keinen Sinn ergibt (z.B. bei einer Bürgerkarten-Umgebung für Blinde).
Im Fall der Signaturprüfung MUSS die Bürgerkarten-Umgebung für jedes Bild, das in einem Instanzdokument referenziert wird, wie folgt vorgehen:
Wurde eine Referenz auf das Bild in die zu prüfende Signatur
entsprechend dem Abschnitt 4, „Bilder im Standard-Anzeigeformat“ inkludiert,
MUSS die Bürgerkarten-Umgebung
dieses Bild als Teil des Instanzdokuments darstellen. Ist dies
nicht möglich (z.B. weil Auflösung scheitert, die aufgelösten
Daten nicht interpretiert werden können, oder die Darstellung von
Bildern nicht durchführbar ist -
Bürgerkarten-Umgebung für Blinde),
MUSS sie das Instanzdokument
zurückweisen. Das Attribut alt
zum Element
img
DARF in diesem Fall
NICHT angezeigt werden.
Fehlt für ein referenziertes Bild hingegen die
korrespondierende Referenz entsprechend dem Abschnitt 4, „Bilder im Standard-Anzeigeformat“ in der zu prüfendenden Signatur,
DARF die
Bürgerkarten-Umgebung dieses Bild
NICHT als Teil des Instanzdokuments
darstellen. Stattdessen MUSS sie den Text
des Attributs alt
darstellen.
Das Bildformat [JPEG]
MUSS von der Anzeigekomponente einer
Bürgerkarten-Umgebung
unterstützt werden. Enhält eine [JPEG]-Datei jedoch
Marker vom Typ TEM
, JPG
, JPGn
(n>=0
), RSTn
(n>=0
) oder
APPn
(n>0
), MUSS
das Instanzdokument von der Bürgerkarten-Umgebung
zurückgewiesen werden.
Das Bildformat [GIF]
MUSS von der Anzeigekomponente einer
Bürgerkarten-Umgebung
ebenfalls unterstützt werden. Enthält eine
[GIF]-Datei jedoch mehrere Bilder
(Animated GIF) oder eine Application
Extension, MUSS das
Instanzdokument von der Bürgerkarten-Umgebung
zurückgewiesen werden. Eine [GIF]-Datei
DARF Erweiterungen vom Typ Comment
Extension
sowie Plain Text Extension
beinhalten,
der Inhalt dieser Erweiterungen DARF jedoch
NICHT angezeigt werden.
Weitere Bildformate DÜRFEN von der Anzeigekomponente einer Bürgerkarten-Umgebung unterstützt werden. Die Bürgerkarten-Umgebung MUSS dabei jedoch verhindern, dass dynamischen Inhalte angezeigt werden (z.B. durch animierte Bilder) .
Die Attribute title
und xml:space
zum
Element style
werden gestrichen. Das Attribut
type
zum Element style
wird vorgeschrieben
und auf den Wert text/css
fixiert. Das Attribut
media
zum Element style
wird ebenfalls
vorgeschrieben und auf den Wert screen
fixiert.
Das Inhaltsmodell für das Element style
bleibt
unverändert.
Anmerkung: Für den erlaubten Inhalt des Elements
style
siehe Abschnitt 3, „Profil von CSS 2“.
Die im vorigen Abschnitt angegebenen Einschränkungen sind als XML-Schema zusammengefasst und formalisiert. Dieses XML-Schema ist als normativ anzusehen und hat bei Unklarheiten Vorrang gegenüber dieser textuellen Beschreibung. Das XML-Schema besteht aus einer Vielzahl von einzelnen Dateien und kann in gepackter Form von folgender Adresse heruntergeladen werden:
slxhtml.schemas.zip
Die Hauptschema-Datei kann weiters direkt von folgender Adresse geladen werden:
slxhtml.xsd
Kommentare sind ein Bestandteil von [XHTML 1.1] mit einer klar festgelegten Bedeutung. Aus dieser Bedeutung geht hervor, dass es sich dabei um Informationen handelt, die nicht für die Anzeige vorgesehen sind ist. Aus diesem Grund DARF ein Instanzdokument Kommentare enthalten. Die Kommentare DÜRFEN von der Anzeigekomponente einer Bürgerkarten-Umgebung NICHT angezeigt werden.
Bestandteile eines Instanzdokuments, die zwar laut
[XHTML 1.1] von einer Anzeige dargestellt werden
dürfen, für die aber kein verpflichtendes Rendering auf der
Zeichnungsebene vorgesehen ist, DÜRFEN von
der Anzeigekomponente einer Bürgerkarten-Umgebung
NICHT angezeigt werden. Als Beispiel sei hier
der Inhalt des Elements title
([XHTML
1.1] schlägt eine Anzeige in der Titelleiste des
Anzeigefensters vor) erwähnt.
Das in diesem Abschnitt angegebene Profil von [CSS 2] legt zunächst jenes Mindestmaß der CSS2-Syntax fest, die von jeder Bürgerkarten-Umgebung im Rahmen der Anzeige eines Dokuments, das diesem Standard-Anzeigeformat entspricht, verarbeitet werden können MUSS bzw. SOLLTE.
Darüber hinaus DARF jede Bürgerkarten-Umgebung auch die nicht in diesem Profil angegebenen syntaktischen Konstrukte aus CSS2 verarbeiten und zur Anzeige bringen, wenn dies in den folgenden Abschnitten nicht ausdrücklich untersagt wird.
Kann eine Bürgerkarten-Umgebung syntaktische Konstrukte, die in dieser Spezifikation als OPTIONAL oder EMPFOHLEN qualifiziert sind, nicht interpretieren, MUSS sie das entsprechende Instanzdokument zurückweisen.
Anwendungsentwickler, die Instanzdokumente schreiben, welche diesem Standard-Anzeigeformat genügen, SOLLTEN nur die in diesem Profil als ERFORDERLICH oder EMPFOHLEN bezeichneten syntaktischen Konstrukte verwenden.
[CSS 2] definiert eine Reihe von Möglichkeiten,
wie CSS-Formate in eine Instanz eines XHTML-Dokuments eingebunden werden
können. Dieses Profil beschränkt diese Möglichkeiten auf eine einzige,
und zwar die Einbindung mittels des XHTML-Elements style
.
Alle anderen Möglichkeiten (Definition über das XHTML-Attribut
style
, sowie die Einbindung externer CSS-Dateien über das
XHTML-Element link
bzw. über die CSS-Regel
@import
) DARF eine Bürgerkarten-Umgebung
NICHT verarbeiten, d. h. das entsprechende
Instanzdokument MUSS zurückgewiesen
werden.
Die Bestimmung der von der Anzeige-Komponente der Bürgerkarten-Umgebung zu verwendenden CSS-Formate erfolgt in zwei Schritten:
Als Ausgangspunkt müssen die Formate des Default-CSS-Stylesheets (vergleiche Abschnitt 3.2.1, „Default-CSS-Stylesheet“) verwendet werden.
Existieren im Instanzdokument benutzerdefinierte CSS-Formate (vergleiche Abschnitt 3.1, „Einbindung von CSS-Formaten in das Standard-Anzeigeformat“), MÜSSEN diese benutzerdefinierten Formate jene des Default-CSS-Stylesheets überschreiben.
Die aus diesen zwei Schritten resultierenden CSS-Formate MÜSSEN von der Anzeigekomponente der Bürgerkarten-Umgebung für die Anzeige des Instanzdokuments berücksichtigt werden.
Der als Ausgangspunkt zur Bestimmung der von der Bürgerkarten-Umgebung bei der Anzeige anzuwendenden CSS-Formate zu verwendende Default-CSS-Stylesheet ist normativer Bestandteil dieser Spezifikation und kann unter folgender Adresse heruntergeladen werden:
slxhtml.default.css
Anmerkung: Es ist nicht notwendig, dass die Anzeigekomponente der Bürgerkarten-Umgebung den Default-Stylesheet interpretieren können muss. Vielmehr MUSS sie dafür Sorge tragen, dass das angezeigte Instanzdokument so aussieht, als sei es unter Interpretation des Default-Stylesheets entstanden. Insofern ist es kein Widerspruch, dass im Default-Stylesheet CSS-Eigenschaften und Eigenschaftswerte verwendet werden, die laut dieser Spezifikation nicht verpflichtend unterstützt werden müssen.
Hinsichtlich der in [CSS 2] definierten @-Regeln gelten für eine Bürgerkarten-Umgebung folgende Regeln:
Die @charset
Regel zur Angabe der Zeichenkodierung
eines externen Stylesheets DARF in einem
Instanzdokument NICHT verwendet werden, da
diese Spezifikation ausschließlich die Verwendung von eingebetteten
Stylesheets erlaubt (siehe Abschnitt 3.1, „Einbindung von CSS-Formaten in das Standard-Anzeigeformat“),
und die @charset
Regel in solchen Stylesheets
NICHT verwendet werden
DARF (vgl. [CSS 2],
Abschnitt 4.4). Die Anzeigekomponente der
Bürgerkarten-Umgebung MUSS ein
Instanzdokument, das eine @charset
Regel enthält,
zurückweisen.
Die @import
Regel zur Einbindung externer
CSS-Dateien DARF in einem Instanzdokument
NICHT verwendet werden (vgl. [CSS
2], Abschnitt 6.3, sowie Abschnitt 3.1, „Einbindung von CSS-Formaten in das Standard-Anzeigeformat“ dieses Dokuments). Die
Anzeigekomponente der Bürgerkarten-Umgebung
MUSS ein Instanzdokument, das eine
@import
Regel enthält, zurückweisen.
Die @media
Regel zur Angabe von
Stylesheet-Information für bestimmte Ausgabemedien
DARF in einem Instanzdokument
NICHT verwendet werden (vgl. [CSS
2], Abschnitt 7). Die Anzeigekomponente der
Bürgerkarten-Umgebung MUSS ein
Instanzdokument, das eine @media
Regel enthält,
zurückweisen.
Die @page
Regel zur Festlegung der
Seiteneigenschaften für seitenorientierte Ausgabemedien
DARF von einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt 13,
sowie Abschnitt 3.5.7, „Seitenorientierte Medien“
dieses Dokuments).
Die @font-face
Regel zur Beschreibung bzw.
Referenzierung zusätzlicher Schriftfamilien (vgl. [CSS
2], Abschnitt 15.3) DARF in einem
Instanzdokument NICHT verwendet werden. Die
Anzeigekomponente der
Bürgerkarten-Umgebung MUSS ein
Instanzdokument, das eine @font-face
Regel enthält,
zurückweisen.
[CSS 2] definiert in Abschnitt 5 eine Reihe von Regeln für den Aufbau von Selektoren. Dieser Abschnitt legt fest, welche dieser Regeln eine Bürgerkarten-Umgebung verarbeiten können MUSS; und zwar sind das:
universal selectors
type selectors
class selectors
ID selectors
Die übrigen Selektoren DÜRFEN unterstützt werden:
descendant selectors
child selectors
adjacent selectors
attribute selectors (Ausnahme: class selectors)
pseudo classes
pseudo elements
Dieser Abschnitt legt die generellen Anforderungen hinsichtlich der zu unterstützenden Wertangaben für CSS-Eigenschaften fest. Sie gelten für alle anwendbaren CSS-Eigenschaften, außer es werden für eine spezielle CSS-Eigenschaft explizit andere Angaben gemacht.
Eine
Bürgerkarten-Umgebung MUSS eine
Längenangabe in den Einheiten in
, mm
,
cm
, pc
und px
und
SOLLTE eine Längenangabe in den relativen
Einheiten ex
und em
für eine
CSS-Eigenschaft unterstützen, wenn laut [CSS 2]
eine solche für diese Eigenschaft möglich ist.
Eine Bürgerkarten-Umgebung MUSS eine prozentuelle Wertangabe für eine CSS-Eigenschaft unterstützen, wenn laut [CSS 2] eine solche für diese Eigenschaft möglich ist.
Eine Bürgerkarten-Umgebung MUSS für eine CSS-Eigenschaft sämtliche in [CSS 2], Abschnitt 4.3.6 aufgeführten Möglichkeiten zur Angabe einer Farbe unterstützen, wenn laut [CSS 2] eine solche für diese Eigenschaft möglich ist.
Die Ausnahme bilden die Systemfarben (vgl. [CSS 2], Abschnitt 18.2); diese DÜRFEN in einem Instanzdokument nicht verwendet werden, um Abhängigkeiten von den Systemumgebung auszuschließen. Widrigenfalls MUSS das Instanzdokument von der Bürgerkarten-Umgebung zurückgewiesen werden.
Für Eigenschaften, die laut dieser Spezifikation von einer
Bürgerkarten-Umgebung
unterstützt werden MÜSSEN oder
SOLLTEN, SOLLTEN
jedenfalls auch die Eigenschaftswerte inherit
bzw.
auto
unterstützt werden, wenn laut [CSS
2] solche Werte für die Eigenschaft möglich sind.
Die Eigenschaften margin-top
,
margin-bottom
, margin-left
und
margin-right
MÜSSEN von einer
Bürgerkarten-Umgebung unterstützt werden. Prozentuell
angegebene Werte (vgl. Abschnitt 3.5.1.2, „Prozentwerte“)
SOLLTEN unterstützt werden.
Die Eigenschaft margin
DARF von einer Bürgerkarten-Umgebung
unterstützt werden.
Ein Instanzdokument DARF in den oben genannten Eigenschaften NICHT negative Wert enthalten. Widrigenfalls MUSS es von der Bürgerkarten-Umgebung zurückgewiesen werden.
Die Eigenschaften padding-top
,
padding-bottom
, padding-left
und
padding-right
MÜSSEN von einer
Bürgerkarten-Umgebung unterstützt werden. Prozentuell
angegebene Werte (vgl. Abschnitt 3.5.1.2, „Prozentwerte“)
SOLLTEN unterstützt werden.
Die Eigenschaft padding DARF von einer Bürgerkarten-Umgebung unterstützt werden.
Ein Instanzdokument DARF in den oben genannten Eigenschaften NICHT negative Werte enthalten. Widrigenfalls MUSS es von der Bürgerkarten-Umgebung zurückgewiesen werden.
Die Eigenschaften border-top-width
,
border-bottom-width
, border-left-width
,
border-right-width
und border-width
SOLLTEN von einer Bürgerkarten-Umgebung
unterstützt werden. Werden die Eigenschaften unterstützt,
SOLLTEN auch die vordefinierten Werte
thin
, medium
und thick
unterstützt werden (vgl. [CSS 2], Abschnitt
8.5.1).
Die Eigenschaften border-top-color
,
border-bottom-color
, border-left-color
,
border-right-color
und border-color
SOLLTEN von einer Bürgerkarten-Umgebung
unterstützt werden. Der vordefinierte Wert
transparent
für die Eigenschaft
border-color
DARF
unterstützt werden (vgl. [CSS 2], Abschnitt
8.5.2).
Die Eigenschaften border-top-style
,
border-bottom-style
, border-left-style
,
border-right-style
und border-style
SOLLTEN von einer
Bürgerkarten-Umgebung unterstützt werden. Werden die
Eigenschaften unterstützt, SOLLTEN die
vordefinierten Werte none
, dashed
,
dotted
, solid
und double
unterstützt werden; alle übrigen Werte
DÜRFEN unterstützt werden (vgl.
[CSS 2], Abschnitt 8.5.3).
Die Eigenschaften für die verkürzte Schreibeweise der
Rahmeneigenschaften (border-top
,
border-bottom
, border-left
,
border-right
und border
- vgl.
[CSS 2], Abschnitt 8.5.4)
SOLLTEN von einer
Bürgerkarten-Umgebung unterstützt werden. Die
EMPFOHLENEN Werte ergeben sich aus den
drei vorigen Abschnitten.
Die Eigenschaft zur Steuerung des Box-Typs
(display
) DARF von einer
Bürgerkarten-Umgebung
unterstützt werden ( vgl. [CSS 2], Abschnitt
9.2).
Die Eigenschaft zur Festlegung des Positionsierungsschemas für
eine Box (position
, vgl. [CSS 2],
Abschnitt 9.3) DARF in einem
Instanzdokument NICHT enthalten sein, um
Überlappungen von Inhalten auszuschließen. Widrigenfalls
MUSS das Instanzdokument von der Bürgerkarten-Umgebung
zurückgewiesen werden.
Die Eigenschaften zur Festlegung der Abstände einer Box
(top
, bottom
, left
,
right
; vgl. [CSS 2], Abschnitt 9.3)
DÜRFEN in einem Instanzdokument
NICHT enthalten sein, um Überlappungen von
Inhalten auszuschließen. Widrigenfalls MUSS
das Instanzdokument von der
Bürgerkarten-Umgebung zurückgewiesen werden.
Anmerkung: Es wäre nicht unbedingt notwendig, diese
Eigenschaften explizit zu verbieten, da sie nur für Elemente
anzuwenden ist, die positioniert sind, für die also auch die
Eigenschaft position
gesetzt ist. Es ist jedoch auch
nicht sinnvoll, diese Eigenschaften im Stylesheet des
Instanzdokuments quasi als Zombi auftreten zu lassen.
Die Eigenschaften zur Festlegung des Umfließens von Boxen
(float
, clear
)
DÜRFEN von einer Bürgerkarten-Umgebung
unterstützt werden ( vgl. [CSS 2], Abschnitt
9.5).
Die Eigenschaft zur Festlegung der Anordnung von Boxen in der
Tiefe (z-index
; vgl. [CSS 2],
Abschnitt 9.9) DARF in einem
Instanzdokument NICHT enthalten sein, um
Überlappungen von Inhalten auszuschließen. Widrigenfalls
MUSS das Instanzdokument von der Bürgerkarten-Umgebung
zurückgewiesen werden.
Anmerkung: Es wäre nicht unbedingt notwendig, diese
Eigenschaft explizit zu verbieten, da sie nur für Elemente
anzuwenden ist, die positioniert sind, für die also auch die
Eigenschaft position
gesetzt ist. Es ist jedoch auch
nicht sinnvoll, diese Eigenschaft im Stylesheet des
Instanzdokuments quasi als Zombi auftreten zu lassen.
Die Eigenschaften zur Steuerung der Textrichtung
(direction
, unicode-bidi
)
DÜRFEN von einer Bürgerkarten-Umgebung
unterstützt werden ( vgl. [CSS 2], Abschnitt
9.10).
Die Eigenschaften zur Angabe von Breite und Höhe einer Box
(width
, height
, vgl. [CSS
2], Abschnitte 10.2 und 10.5)
DÜRFEN von einer Bürgerkarten-Umgebung
NICHT unterstützt werden, um Überlappungen
von Inhalten auszuschließen. Widrigenfalls
MUSS das Instanzdokument von der Bürgerkarten-Umgebung
zurückgewiesen werden.
Die Eigenschaften zur Angabe der minimalen Breite und Höhe
einer Box (min-width
, min-height
)
DÜRFEN von einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitte 10.4
und 10.7).
Die Eigenschaften zur Angabe der maximalen Breite und Höhe
einer Box (max-width
, max-height
, vgl.
[CSS 2], Abschnitte 10.4 und 10.7)
DÜRFEN von einer Bürgerkarten-Umgebung
NICHT unterstützt werden, um Überlappungen
von Inhalten auszuschließen.Widrigenfalls
MUSS das Instanzdokument von der
Bürgerkarten-Umgebung zurückgewiesen werden.
Die Eigenschaften zur Angabe der Zeilenhöhe
(line-height
, vertical-align
)
SOLLTEN von einer Bürgerkarte unterstützt
werden (vgl. [CSS 2], Abschnitt 10.8). Die
einzige Ausnahme bildet die Eigenschaft vertical-align
:
Hier MUSS eine
Bürgerkarten-Umgebung jedenfalls die Werte
sub
und super
interpretieren
können.
Die Eigenschaft zur Angabe der Sichtbarkeit einer Box
(visibility
) DARF von einer
Bürgerkarten-Umgebung
unterstützt werden - vgl. [CSS 2], Abschnitt
11).
Die Eigenschaften zur Steuerung des sichtbaren Bereichs einer
Box (overflow
, clip
; vgl. [CSS
2], Abschnitt 11) DÜRFEN in einem
Instanzdokument NICHT enthalten sein, um
versteckte Inhalte auszuschließen. Widrigenfalls
MUSS das Instanzdokument von der Bürgerkarten-Umgebung
zurückgewiesen werden.
Die Eigenschaft für die Generierung von Inhalten
(content
) DARF von einer
Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitte
12.2).
Die Eigenschaft für die Darstelung von Anführungszeichen
(quotes
) DARF von einer
Bürgerkarten-Umgebung unterstützt werden (vgl.
[CSS 2], Abschnitte 12.3).
Die Eigenschaften für die automatische Nummerierung
(counter-reset
, counter-increment
)
DÜRFEN von einer Bürgerkarten-Umgebung
unterstützt werden - vgl. [CSS 2], Abschnitt
12.5).
Die Eigenschaft zur Bestimmung des Abstandes zwischen einem
Marker und der zugehörigen Box (marker-offset
)
DARF von einer
Bürgerkarten-Umgebung unterstützt werden (vgl.
[CSS 2], Abschnitt 12.6.1).
Für die Eigenschaft zur Auswahl des Listenzeichens
(list-style-type
) MUSS eine
Bürgerkarten-Umgebung
die Werte none
, disc
,
circle
, square
, decimal
,
decimal-leading-zero
, lower-roman
,
upper-roman
, lower-alpha
,
lower-latin
, upper-alpha
und
upper-latin
unterstützen. Die übrigen Werte
DÜRFEN unterstützt werden (vgl.
[CSS 2], Abschnitt 12.6.2).
Die Eigenschaft zur Positionierung des Listenzeichens in
Bezug auf die zugehörige Box (list-style-position
)
SOLLTE von einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt
12.6.2).
Die Eigenschaft zur Auswahl eines Bildes als Listenzeichen
(list-style-image
) DARF von
einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt
12.6.2). Unterstützt die
Bürgerkarten-Umgebung diese Eigenschaft, so
MUSS sie bezüglich der Einbindung des
Bildes in die Signatur wie im Abschnitt 2.1.7, „Image Module“ beschrieben
vorgehen.
Die Eigenschaft für die Kurzschreibweise der
Listeneigenschaften (list-style
)
SOLLTE von einer Bürgerkarten-Umgebung
unterstützt werden. Die EMPFOHLENEN Werte
ergeben sich aus den obenstehenden Erläuterungen zu den
Eigenschaften list-style-type
,
list-style-position
und list-style-image
(vgl. [CSS 2], Abschnitt 12.6.2).
Die Eigenschaften für seitenorientierte Medien
DÜRFEN von einer Bürgerkarten-Umgebung
unterstützt werden (size
, marks
,
page-break-before
, page-break-inside
,
page-break-after
, page
,
orphans
, widows
- vgl. [CSS
2], Abschnitt 13).
Die Eigenschaft zur Bestimmung der Vordergrundfarbe des
Inhalts eines Elements (color
)
MUSS von einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt
14.1).
Die Eigenschaft zur Bestimmung der Hintergrundfarbe des
Inhalts eines Elements (background-color
; vgl.
[CSS 2], Abschnitt 14.2.1)
MUSS von einer Bürgerkarten-Umgebung
unterstützt werden.
Die Eigenschaften zur Auswahl und Steuerung eines Bildes als
Hintergrund (background-image
,
background-repeat
, background-position
,
background-attachment
; vgl. [CSS 2],
Abschnitt 14.2.1) DÜRFEN in einem
Instanzdokument NICHT enthalten sein, um
Überlappungen von Inhalten auszuschließen. Widrigenfalls
MUSS das Instanzdokument von der
Bürgerkarten-Umgebung zurückgewiesen werden.
Die Eigenschaft für die Kurzschreibweise der
Hintergrundeigenschaften (background
)
SOLLTE von einer
Bürgerkarten-Umgebung unterstützt werden. Die
EMPFOHLENEN Werte ergeben sich aus den
obenstehenden Erläuterungen zur Eigenschaft
background-color
(vgl. [CSS 2],
Abschnitt 14.2.1). Enthält die Eigenschaft Werte zur Auswahl und
Steuerung eines Bildes als Hintergrund,
MUSS das Instanzdokument von der Bürgerkarten-Umgebung
zurückgewiesen werden.
Für die Eigenschaft zur Auswahl der Schriftfamilie
(font-family
) MUSS eine
Bürgerkarten-Umgebung
die vordefinierten Werte serif
, san-serif
und monospaced
für die allgemeinen Schriftfamilien
unterstützen. Alle übrigen Werte DÜRFEN von
einer
Bürgerkarten-Umgebung unterstützt werden (vgl.
[CSS 2], Abschnitt 15.2.2).
Wird im Instanzdokument eine Schriftfamilie, die durch die
Bürgerkarten-Umgebung
nicht dargestellt werden kann, bevorzugt spezifiziert,
DARF die Bürgerkarten-Umgebung
das Instanzdokument trotzdem zur Anzeige bringen, wenn eine weitere,
darstellbare Schriftfamilie als Alternative spezifiziert wurde.
Lautet die Spezifikation im Instanzdokument beispielsweise
font-family: "Times New Roman", serif
,
DARF die Bürgerkarten-Umgebung
das Instanzdokument zur Anzeige bringen, auch wenn sie die
Schriftfamilie Times New Roman nicht kennt
(serif
muss sie ja jedenfalls unterstützen).
Die Eigenschaften zur Bestimmung des Schriftstils
(font-style
) sowie des Schriftgewichts
(font-weight
) MÜSSEN von einer
Bürgerkarten-Umgebung
unterstützt werden. Die Werte normal
und
italic
MÜSSEN, der Wert
oblique
SOLLTE unterstützt
werden. Die Eigenschaft zur Bestimmung der Schriftvariante
(font-variant
) SOLLTE, jene
zur Bestimmung der Schriftstreckung (font-stretch
)
DARF von einer
Bürgerkarten-Umgebung unterstützt werden (vgl.
[CSS 2], Abschnitt 15.2.3).
Die Eigenschaft zur Angabe der Schriftgröße
(font-size
) MUSS von einer
Bürgerkarten-Umgebung
unterstützt werden. Die Eigenschaft für die Spezifikation des
Streckungsverhältnisses (font-size-adjust
)
DARF von einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt
15.2.4).
Die Eigenschaft für die Kurzschreibweise der
Schrifteigenschaften (font
)
SOLLTE von einer
Bürgerkarten-Umgebung unterstützt werden (vgl.
[CSS 2], Abschnitt 15.2.5). Die
EMPFOHLENEN Werte ergeben sich aus den
obenstehenden Erläuterungen zu den Eigenschaften
font-style
, font-variant
,
font-weight
, font-size
und
font-family
, sowie aus den Erläuterungen zur
Eigenschaft line-height
in Abschnitt 3.5.4.2, „Zeilenhöhe“.
Die zusätzlichen vordefinierten Werte mit Bezug auf die
verwendeten Systemschriftarten (caption
,
icon
, etc.) DÜRFEN in einem
Instanzdokument NICHT enthalten sein, um
Abhängigkeiten von der Systemumgebung auszuschließen. Widrigenfalls
MUSS das Instanzdokument von der Bürgerkarten-Umgebung
zurückgewiesen werden.
Enthält der Text eines Instanzdokuments ein Zeichen, das die Bürgerkarten-Umgebung nicht anzeigen kann, MUSS das Instanzdokument von der Bürgerkarten-Umgebung zurückgewiesen werden. Eine alternative Darstellung des Zeichens durch einen Platzhalter DARF NICHT erfolgen.
Die Eigenschaft zur Einrückung der ersten Textzeile eines
Blocks (text-indent
) SOLLTE
von einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt
16.1).
Für die Eigenschaft zur Ausrichtung des Inhalts eines Blocks
(text-align
) MUSS eine
Bürgerkarten-Umgebung
die Werte left
, right
und
center
unterstützen. Der Wert justified
SOLLTE, die Angabe eines String-Werts
DARF unterstützt werden (vgl. [CSS
2], Abschnitt 16.2).
Für die Eigenschaft zur Verzierung eines Texts
(text-decoration
; vgl. [CSS 2],
Abschnitt 16.3.1) MUSS eine Bürgerkarten-Umgebung
die Werte none
, underline
und
line-through
unterstützen.
Der Wert blink
DARF in
einem Instanzdokument NICHT enthalten sein.
Widrigenfalls MUSS das Instanzdokument von
der Bürgerkarten-Umgebung
zurückgewiesen werden.
Die übrigen Werte DÜRFEN von einer Bürgerkarten-Umgebung unterstützt werden.
Die Eigenschaft zur Angabe eines Textschattens
(text-shadow
) DARF von einer
Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt
16.3.2).
Die Eigenschaften für Wortabstand und Zeichenabstand
(word-spacing
, letter-spacing
)
SOLLTEN von einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt
16.4).
Negative Werte DÜRFEN in einem Instanzdokument NICHT enthalten sein, um Überlappungen von Inhalten auszuschließen. Widrigenfalls MUSS das Instanzdokument von der Bürgerkarten-Umgebung zurückgewiesen werden.
Die Eigenschaft zur Angabe der Kapitaliserung von Text eines
Elements (text-transform
) DARF
von einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt
16.5).
Die Eigenschaft zur Behandlung von White Space im Text eines
Elements (white-space
) SOLLTE
von einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt
16.6).
Für die Eigenschaft zur Angabe der Position für die
Beschriftung einer Tabelle (caption-side
)
SOLLTE eine Bürgerkarten-Umgebung
die Eigenschaften top
und bottom
unterstützen; die Eigenschaften left
und
right
DÜRFEN unterstützt
werden (vgl. [CSS 2], Abschnitt 17.4.1).
Die Eigenschaft zur Festlegung des Layout-Algorithmus für eine
Tabelle (table-layout
) DARF
von einer Bürgerkarten-Umgebung
unterstützt werden (vgl. [CSS 2], Abschnitt
17.5.2).
Der Wert fixed
DARF
jedoch NICHT unterstützt werden, da es mit
dem damit selektierten Layout-Algorithmus zu Überlappungen von
Inhalten kommen kann.
Generell MUSS von der Anzeigekomponente der Bürgerkarten-Umgebung ein solchen Layout-Algorithmus für eine Tabelle verwendet werden, der keinen Overflow erzeugt, mit dem also der Inhalt eines jeden Tabellenelements so gerendert wird, dass er nicht über das Tabellenelement hinausragt. Ein Beispiel für einen solchen Algorithmus findet sich in [CSS 2], Abschnitt 17.5.2, Unterabschnitt Automatic table layout.
Die Eigenschaften für die Darstellung von Rändern in Tabellen
(border-collapse
, border-spacing
,
empty-cells
) DÜRFEN von einer
Bürgerkarten-Umgebung unterstützt werden (vgl.
[CSS 2], Abschnitt 17.6).
Die Eigenschaft zur Steuerung der Sprachausgabe der
Spaltenbeschriftung einer Tabelle (speak-header
)
DARF von einer
Bürgerkarten-Umgebung unterstützt werden (vgl.
[CSS 2], Abschnitt 17.7.1).
Die Eigenschaft zur Steuerung der Form des Cursors
(cursor
; vgl. [CSS 2], Abschnitt
18.1) DARF in einem Instanzdokument
NICHT enthalten sein. Widrigenfalls
MUSS das Instanzdokument von der
Bürgerkarten-Umgebung zurückgewiesen werden.
Anmerkung: Prinzipiell ist es nicht notwendig, diese Eigenschaft zu verbieten, ihre Verwendung macht aber auch keinen Sinn, da sie nicht auf die Zeichnungsebene bezogen ist. Im Sinne einer möglichst schlanken Spezifikation wird die Eigenschaft daher verboten.
Die Eigenschaften zur Festlegung von Konturen von Elementen
(outline-width
, outline-style
,
outline-color
und outline
; vgl.
[CSS 2], Abschnitt 18.4)
DÜRFEN in einem Instanzdokument nicht
enthalten sein. Widrigenfalls MUSS das
Instanzdokument von der Bürgerkarten-Umgebung
zurückgewiesen werden.
Anmerkung: Prinzipiell ist es nicht notwendig, diese Eigenschaften zu verbieten, ihre Verwendung macht aber auch keinen Sinn, da sie auf Elemente bezogen sind, die in einem Instanzdokument nicht enthalten sein dürfen. Im Sinne einer möglichst schlanken Spezifikation wird die Eigenschaft daher verboten.
Die Eigenschaften für die Sprachausgabe eines Dokuments (vgl. [CSS 2], Abschnitt 19) DÜRFEN von einer Bürgerkarten-Umgebung unterstützt werden.
Wie aus den Abschnitt 2, „Profil von XHMTL 1.1“ und Abschnitt 3, „Profil von CSS 2“ hervorgeht, erlaubt das in diesem Dokument spezifizierte Standard-Anzeigeformat auf zweifache Weise die Integration von Bildern:
mittels <img>
-Tag (vgl. Abschnitt 2.1.7, „Image Module“);
mittels CSS-Eigenschaft zur Auswahl eines Bildes als Listenzeichen (vgl. „Bild als Listenzeichen“).
Nachdem die somit integrierten Bilder nicht direkt in das Instanzdokument eingebunden, sondern nur mittels URI referenziert werden, müssen die referenzierten Bilddaten als zusätzliche Daten neben dem eigentlichen Instanzdokument in die XML-Signatur aufgenommen werden. Die nachfolgenden Abschnitte spezifizieren diese Integration.
Für jedes Bild, dass auf eine der zwei oben erwähnten Arten in
einem Instanzdokument referenziert wird und mitsigniert werden soll
(vergleiche die Alternativen in Abschnitt 2.1.7, „Image Module“),
MUSS in die XML-Signatur (neben dem
dsig:Reference
Element für das Instanzdokument) ein
weiteres dsig:Reference
Element aufgenommen werden. Dabei
sind folgende Regeln einzuhalten:
Das Attribut URI
des dsig:Reference
Elements MUSS jene URI beinhalten, mit der
das entsprechende Bild im Instanzdokument referenziert wird;
Das Attribut Type
des dsig:Reference
Elements ist zu verwenden und MUSS wie
folgt aufgebaut
sein:http://www.buergerkarte.at/specifications/Security-Layer/20031031?Name=SignedImage&InstanceDocRef=x
Der Platzhalter x
in der letzten Zeile ist durch den
Index jenes dsig:Reference
Elements zu ersetzen, das
zum Integrieren des Instanzdokuments in die Signatur verwendet wird.
Die erste dsig:Reference
der Signatur trägt den Index
0
. Wird das selbe Bild in mehrere Instanzdokumente
eingebunden, sind die Indizes der Instanzdokument-Referenzen durch
Beistriche voneinander zu trennen.
Das folgende Instanzdokument soll von der Bürgerkarten-Umgebung signiert werden:
<?xml version="1.0" encoding="UTF-8"?> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Beispiel</title> <style type="text/css"> ul { list-style-image: url("http://example.com/list-style.gif") } </style> </head> <body> <p> Dieses Bild wird mitsigniert: <img src="http://example.com/image.gif" alt="Example"/> </p> <ul> <li>Das ist ein mittels Bild dargestellter Listenpunkt.</li> </ul> </body> </html>
Die dafür notwendige XML-Signatur sieht skizzenhaft wie folgt aus (drei Punkte ... signalisieren Auslassungen aus Gründen der Übersichtlichkeit):
<?xml version="1.0" encoding="UTF-8"?> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> ... <Reference URI="http://example.com/instanceDocument.xhtml"> ... </Reference> <Reference URI=http://example.com/image.gif" Type="...ayer/20031031?Name=SignedImage&InstanceDocRef=0"> </Reference> <Reference URI="http://example.com/list-style.gif" Type="...ayer/20031031?Name=SignedImage&InstanceDocRef=0"> </Reference> </SignedInfo> ... </Signature>
Anmerkung: Der Wert des Attributs URI
der
ersten Reference wurde willkürlich gewählt. Der tatsächlich zu
verwendende Wert hängt vom Signaturerstellungsrequest ab, der an die
Bürgerkarten-Umgebung gesendet wurde.
Die beiden nachfolgenden Abschnitte beschreiben das von einer Bürgerkarten-Umgebung einzuhaltende Prozessmodell bei der Verarbeitung von Dokumenten, die dem in diesem Dokument festgeschriebenen Standard-Anzeigeformat genügen, im Rahmen von Signaturerstellung bzw. Signaturprüfung.
Für jedes Instanzdokument, das signiert werden soll, führe folgende Schritte durch:
Prüfe, ob das Instanzdokument den Regeln dieser Spezifikation entspricht.
Füge ein dsig:Reference
Element für das
Instanz-Dokument in die XML-Signatur ein.
Prüfe, ob das Instanzdokument referenzierte Bilder enthält. Falls ja, führe für jedes referenzierte Bild, das mitsigniert werden soll, folgende Schritte durch:
Prüfe, ob das referenzierte Bild bereits mit
einem zusätzlichen dsig:Reference
in der
XML-Signatur berücksichtigt wurde.
Falls ja, erweitere das Attribut Type dieses
dsig:Reference
Elements um den Index
des mit dem Instanzdokument korrespondierenden
dsig:Reference
Elements, wenn der Index
nicht schon berücksichtigt wurde.
Falls nein, füge ein zusätzliches
dsig:Reference
Element für das Bild in
die XML-Signatur ein.
Fahre in der Erstellung der XML-Signatur wie für Dokumente anderer Formate fort.
Prüfe die Gültigkeit der XML-Signatur an Hand des Prozessmodells aus [XMLDSIG].
Für jedes durch die XML-Signatur abgedeckte Instanzdokument führe folgende Schritte durch:
Prüfe, ob das Instanzdokument referenzierte Bilder enthält. Falls ja, führe für jedes referenzierte Bild folgende Schritte durch:
Prüfe, ob das referenzierte Bild mit einer entsprechenden zusätzlichen dsig:Reference-Element in der XML-Signatur berücksichtigt ist.
Melde all jene referenzierten Bilder als Ergebnis der Signaturprüfung, die mit einer entsprechenden zusätzlichen dsig:Reference-Element in der XML-Signatur berücksichtigt ist.(Anmerkung: Die Bürgerkarten-Umgebung kann mit dieser Information dann entsprechend den Vorgaben aus Abschnitt 2.1.7, „Image Module“ weiterverfahren).
Jenes Programm, das Anfragen an die Bürgerkarten-Umgebung über den Security-Layer richtet und die entsprechenden Antworten entgegennimmt und auswertet.
Jene Schnittstelle, über die der Bürger mit der Bürgerkarten-Umgebung kommuniziert. Über diese Schnittstelle wird einerseits die Benutzerinteraktion abgewickelt, die gegebenenfalls zur Abwicklung eines Befehls des Security-Layers notwendig ist (z.B. die Anzeige eines zu signierenden Dokuments beim Befehl zur Erzeugung einer XML-Signatur); andererseits kann der Bürger über diese Schnittstelle seine Bürgerkarten-Umgebung nach seinen persönlichen Bedürfnissen konfigurieren (z.B. kann er Einstellungen zum Zugriffsschutz auf seine Infoboxen verändern). Die Vorgaben an die Benutzer-Schnittstelle sind in Minimale Umsetzung des Security-Layers geregelt.
Jene Person, die die Funktionen der Bürgerkarten-Umgebung für die sichere Abwicklung von E-Government oder E-Commerce verwenden möchte. Die Ansteuerung der Bürgerkarten-Umgebung erfolgt in der Regel nicht durch den Bürger selbst, sondern durch die Applikation, welche die E-Government oder E-Commerce Anwendung repräsentiert.
Laut [E-GovG], §10 ZI 10 ist die Bürgerkarte „die unabhängig von der Umsetzung auf unterschiedlichen technischen Komponenten gebildete logische Einheit, die eine elektronische Signatur mit einer Personenbindung (§ 4 Abs. 2) und den zugehörigen Sicherheitsdaten und -funktionen sowie mit allenfalls vorhandenen Vollmachtsdaten verbindet“. Im Sinne der in den Spezifikationen zur österreichischen Bürgerkarte gebrauchten Terminologie ist die Bürgerkarten-Umgebung die Implementierung der logischen Einheit Bürgerkarte.
Jenes Programm bzw. jener Dienst, der die Funktionalität der Bürgerkarte zur Verfügung stellt. Grundsätzlich vorstellbar ist die Ausführung als Programm, das lokal am Rechner des Bürgers läuft (lokale Bürgerkarten-Umgebung), oder als serverbasierter Dienst, der über das Internet angesprochen wird (serverbasierte Bürgerkarten-Umgebung). Die Interaktion mit diesem Programm bzw. Dienst wird über zwei Schnittstellen abgewickelt: Über die Benutzer-Schnittstelle sowie über den Security-Layer.
Jene Daten, die für die Berechnung des Hash-Wertes für eine
dsig:Reference
verwendet werden. Sind für die
dsig:Reference
Transformationen angegeben, entsprechen
diese Daten dem Ergebnis der letzten Transformation. Sind keine
Transformationen spezifiziert, gleichen die Hash-Eingangsdaten den
Referenz-Eingangsdaten.
Siehe Abschnitt 2.2.2.2, „Implizite Transformationsparameter“ in
Jene Daten, die sich aus der Auflösung der im Attribut
URI
der dsig:Reference
angegebenen URI
ergeben. Sind für die dsig:Reference
Transformationen
angegeben, werden diese Daten als Eingangsdaten zur Berechnung der
ersten Transformation verwendet. Sind keine Transformationen
spezifiziert, gleichen die Referenz-Eingangsdaten den Hash-Eingangsdaten.
Jene Schnittstelle, über die die Applikation mit der Bürgerkarten-Umgebung kommuniziert. Das genaue Protokoll, das über diese Schnittstelle gesprochen werden kann, wird in Applikationsschnittstelle Security-Layer spezifiziert. Die möglichen Bindungen dieses Protokolls an Transportschichten wie HTTP oder TCP wird in Transportprotokolle Security-Layer geregelt.
Siehe Abschnitt 2.2.2.2, „Implizite Transformationsparameter“ in
[BSI TR-03111] Bundesamt für Sicherheit in der Informationstechnik: Technical Guideline TR-03111: Elliptic Curve Cryptography, Technical Guideline, Juni 2012
[CAdES] European Telecommunications Standards Institute: ETSI TS 101733: Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures (CAdES) v2.2.1 , Technical Specification, April 2013
[CAdES-Baseline] European Telecommunications Standards Institute: ETSI TS 103173: Electronic Signatures and Infrastructures (ESI); CAdES Baseline Profile v2.2.1 , Technical Specification, April 2013
[CMS] Housley, R.: RFC 5652: Cryptographic Message Syntax (CMS) , IETF Request For Comment, September 2009
[CMS-AES] chaad, J.: RFC 3565: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS) . IETF Request For Comment, Juli 2003.
[CMS-Alg] Housley, R.: RFC 3370: Cryptographic Message Syntax (CMS) Algorithms . IETF Request For Comment, August 2002.
[CMS-RSAES-OAEP] Housley, R.: RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS) . IETF Request For Comment, Juli 2003.
[CSS 2] Bert Bos, Håkon Wium Lie, Chris Lilley und Ian Jacobs: Cascading Style Sheets, level 2 . W3C Recommendation, Mai 1998.
[EC14N] Boyer, John, Eastlake, Donald und Reagle, Joseph: Exclusive XML Canonicalization. W3C Recommendation, Juli 2002 .
[ECDSA-CMS] Turner, S., Brown, D.: RFC 5753: Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) . IETF Request For Comment, Jänner 2010.
[ECDSA-XML] Blake-Wilson, S., Karlinger, G. und Wang, Y.: ECDSA with XML-Signature Syntax . Internet-Draft, Jänner 2004.
[ESS-S/MIME] Hoffman, P.: RFC 2634: Enhanced Security Services for S/MIME , IETF Request For Comment, Juni 1999
[ETSICMS] European Telecommunications Standards Institute: ETSI TS 101733: Electronic Signature Formats, v1.5.1 , Technical Specification, Dezember 2003
[ETSIQCert] European Telecommunications Standards Institute: ETSI TS 101 862: Qualified certificate profile, v1.2.1 , Technical Specification, Juni 2001
[ETSIXML] European Telecommunications Standards Institute: ETSI TS 101903: XML Advanced Electronic Signatures (XAdES), v1.2.2 , Technical Specification, April 2004
[GIF] Graphics Interchange Format, Version 89a . CompuServe Incorporated, Juli 1990.
[HTML4] Dave Ragget, Arnaud Le Hors und Ian Jacobs: HTML 4.01 Specification . W3C Recommendation, Dezember 1999.
[HTTP1.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.
[HTTPS] E. Rescorla HTTP over TLS. IETF Request For Comment, Mai 2000
[ISO-8859-1] ISO/IEC 8859-1:1998: Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1.
[ISO-8859-10] ISO/IEC 8859-10:1998: Information technology -- 8-bit single-byte coded graphic character sets -- Part 10: Latin alphabet No. 6.
[ISO-8859-15] ISO/IEC 8859-15:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 15: Latin alphabet No. 9.
[ISO-8859-2] ISO/IEC 8859-2:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 2: Latin alphabet No. 2.
[ISO-8859-3] ISO/IEC 8859-3:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 3: Latin alphabet No. 3.
[ISO-8859-9] ISO/IEC 8859-9:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 9: Latin alphabet No. 5.
[JPEG] Eric Hamilton: JPEG File Interchange Format, Version 1.02 . C-Cube Microsystems, September 1992.
[KEYWORDS] Bradner, S.: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels , IETF Request For Comment, März 1997
[MIME] Freed, N. und Borenstein, N.: RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types , IETF Request For Comment, November 1996
[PAdES] European Telecommunications Standards Institute: ETSI TS 102778: Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles v1.2.1 , Technical Specification, Juli 2010
[PersBin] Hollosi, Arno und Karlinger, Gregor: XML-Definition der Personenbindung . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards. Öffentlicher Entwurf, Version 1.2.2, 14. Februar 2005.
[PersonData] Naber, Larissa: PersonData Struktur - XML Spezifikation . Konvention zum E-Government Austria erarbeitet von der Arbeitsgruppe Kommunikationsarchitekturen. Öffentlicher Entwurf, Version 2.0.0, 14. Oktober 2004.
[PKCS#12] RSA Laboratories: PKCS#12 v1.0: Personal Information Exchange Syntax , Juni 1999.
[port-numbers] Internet Assigned Numbers Authority: Port Numbers
[QCert] Santesson, S. und Nystrom M.: RFC 3739: Internet X.509 Public Key Infrastructure: Qualified Certificates Profile , IETF Request For Comment, März 2004
[RFC 5035] Schaad, J.: RFC 5035: Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility , IETF Request For Comment, August 2007
[SHA2-CMS] Turner, S.: RFC 5754: Using SHA2 Algorithms with Cryptographic Message Syntax , IETF Request For Comment, Jänner 2010
[Stammzahl] Hollosi, Arno und Hörbe, Rainer: Bildung von Stammzahl und bereichsspezifischem Personenkennzeichen (bPK) . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards sowie vom Bundesminsterium für Inneres. Öffentlicher Entwurf, Version 1.0, 2. Februar 2004.
[TLS] T. Dierks und C. Allen: The TLS Protocol Version 1.0 . IETF Request For Comment, Januar 1999.
[Unicode] The Unicode Consortium. The Unicode Standard, Version 4.0.0 , defined by: The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1).
[URI] Berners-Lee, T. , Fielding, R. und Masinter, L.: RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax , IETF Request For Comment, August 1998
[VerwEig] Hollosi, Arno: X.509 Zertifikatserweiterungen für die Verwaltung . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards. Öffentlicher Entwurf, Version 1.0.3, 21. Februar 2005.
[X509] Polk, W., Ford, W., Solo, D.: RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile . IETF Request For Comment, April 2002.
[XAdES] European Telecommunications Standards Institute: ETSI TS 101903: XML Advanced Electronic Signatures (XAdES), v1.4.2 , Technical Specification, Dezember 2010
[XHTML 1.1] Murray Altheim, Frank Boumphrey, Sam Dooley, Shane McCarron, Sebastian Schnitzenbaumer und Ted Wugofski: Modularization of XHTML . W3C Recommendation, April 2001.
[XHTML MOD] Daniel Austin, Subramanian Peruvemba, Shane McCarron, Masayasu Ishikawa: Modularization of XHTML in XML Schema . W3C Working Draft, Oktober 2003.
[XML] Bray, Tim, Paoli, Jean, Sperberg-McQueen, C.M. und Maler, Eve: Extensible Markup Language (XML) 1.0 (Second Edition) , W3C Recommendation, Oktober 2000.
[XMLDecTF] Hughes, Merlin, Imamura, Takeshi und Maruyama, Hiroshi: Decryption Transform for XML Signature . W3C Recommendation, Dezember 2002.
[XMLDSIG] Eastlake, Donald, Reagle, Joseph und Solo, David: XML-Signature Syntax and Processing , W3C Recommendation, Februar 2002
[XMLDSIG-URI] Eastlake, Donald: RFC 4051: Additional XML Security Uniform Resource Identifiers (URIs) , IETF Request For Comments, April 2005
[XMLEnc] Eastlake, Donald und Reagle, Joseph: XML Encryption Syntax and Processing , W3C Recommendation, Dezember 2002
[XML-Schema] Thompson, Henry S., Beech, David, Maloney, Murray und Mendelson, Noah: XML Schema Part 1: Structures , W3C Recommendation, Mai 2001
[XMLTYPE] Murata, M., St.Laurent, S., und Kohn, D.: RFC 3023: XML Media Types , IETF Request For Comment, Jänner 2001.
[XPath] Clark, James und DeRose, Steven: XML Path Language , W3C Recommendation, November 1999
[XPF2] Boyer, John, Hughes, Merlin und Reagle, Joseph: XML-Signature XPath Filter 2.0 . W3C Candidate Recommendation, Juli 2002.
[XPointer] Grosso, Paul, Maler, Eve, Marsh, Jonathan und Walsh, Norman: XPointer Framework . W3C Recommendation, März 2003.
[XSS-FAQ] Cgisecurity.com: The Cross Site Scripting FAQ .
Datum | Version | Änderungen |
---|---|---|
01.03.2005 | 1.2.1 |
|
14.05.2004 | 1.2.0 |
|
18.12.2003 | 1.0.1 |
|
13.11.2003 | 1.0 |
|
22.10.2003 | 0.9 |
|
25.08.2003 | 0.4 |
|
17.07.2003 | 0.3 |
|