XTA 2 - Interoperabilitätsstandard zur Einbindung von IT-Fachapplikationen in eine Infrastruktur für Nachrichtenübermittlung
XTA 2
xta2
urn:xoev-de:kosit:standard:xta2
XTA ist ein vom IT-Planungsrat empfohlener Interoperabilitätsstandard. XTA (XÖV Transport Adapter) definiert einen Webservice für die Anbindung von IT-Fachapplikationen an eine technische Infrastruktur für Nachrichtenübermittlung (Transportverfahren). Diese Webservice-Definition (genannt XTA-Webservice) ist für alle Fachlichkeiten einsetzbar. Außerdem bietet XTA Definitionen für Struktur und Semantik von "Service Profilen" an. Mittels eines instanziierten "XTA Service Profils" formuliert eine Fachlichkeit die durch sie geforderten Service Qualitäten für die Nachrichten- und Datenübermittlung dieser Fachlichkeit.
2.2
1.5.1
2.1
3.0.1
18.0 SP6
MagicDraw
Dieser Typ beinhaltet Parameter für Identifikation und Beschreibung eines kryptographischen Algorithmus.
Hier steht die Zeichenfolge, die zur Identifizierung des Algorithmus dient.
Hier ist das Datum zu nennen, bis zu dem der Algorithmus gültig ist.
Hier besteht die Möglichkeit, eine Bemerkung zu diesem Algorithmus einzutragen.
Dieser Typ bildet einen Algorithmus für asymmetrische Verschlüsselung ab. Er ergänzt den Typ Algorithmus um einen weiteren Parameter.
Hier ist die zu verwendende Schlüssellänge einzutragen.
Dieser Typ bildet eine Algorithmus-Deklaration für Cipher-Suiten ab.
Die Quelle beschreibt die Herkunft des Algorithmus. Hier kann z. B. WS-Security policy Spec oder BSI Algo Catalog stehen.
Dieser Typ bietet den Rahmen, um ein Set von Krypto-Suiten zu definieren, die für die kryptographische Umsetzung der Anforderungen aus Schutz- und Infrastrukturprofilen benötigt werden.
Ein Element bildet die Definition einer Krypto-Suite ab. Eine Krypto-Suite ist eine Zusammenstellung von kryptographischen Mitteln (Algorithmen und Schlüssellängen), jeweils zugeordnet einem bestimmen Schutzniveau einer kryptographisch abzusichernden Kommunikation. Wenn mehrere Verfahren vorgegeben werden, liegt es in der Zuständigkeit der Rolle Sender, das für einen gegebenen Transportauftrag geeignete Verfahren unter Berücksichtigung der Qualitätsanforderung in cryptoQuality auszuwählen. Die Auswahl muss im ServiceReport durch das Ereignis AuswahlServicequalitaet protokolliert werden. Wenn keine der angegebenen Krypto-Suiten verwendet werden konnte, ist die Servicequalität nicht erfüllt.
Eine Krypto-Qualität benennt eine Abstufung (z. B. hoch, normal, niedrig) des geforderten Schutzniveaus einer kryptographisch zu sichernden Kommunikation. Das hier einzustellende Niveau korrespondiert mit den Elementen namens qualitaet aus dem Schutzprofil in den Kontexten der Servicequalitäten Authentizität, Unveränderbarkeit und Vertraulichkeit (vgl. und ).
Unterhalb dieses Elements wird einem bestimmten Schutzniveau einer kryptographisch abzusichernden Kommunikation (gelistete Krypto-Qualität, festgelegt durch das Element cryptoQuality) ein Set von Algorithmen und Schlüssellängen zugeordnet. Wenn mehrere Algorithmen vorgegeben werden, liegt es in der Zuständigkeit der Rolle Sender, den für einen gegebenen Transportauftrag geeigneten Algorithmus unter Berücksichtigung der Qualitätsanforderung in cryptoQuality auszuwählen. Die Auswahl muss im ServiceReport durch das Ereignis AuswahlServicequalitaet protokolliert werden. Wenn keiner der angegebenen Algorithmen verwendet werden konnte, ist die Servicequalität nicht erfüllt.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Auf die Umsetzung dieses Transportnachrichtenformats oder Protokolls bezieht sich diese Krypto-Suite. Die Krypto-Suite beschreibt die kryptographischen Mittel vor für die Kontexte OSCI 1.2, TLS und Payload (Fachnachrichten).
Dieser Typ wird verwendet zur Darstellung der Parameter zu Identität und Herkunft eines Profils (versionsübergreifend verstanden) bzw. einer Profil-Instanz.
Hier ist eine URI einzutragen, durch die diese Profil-Instanz identifiziert wird. Die Bezeichnung hat die Form einer URN mit angehänger Versionsnummer. Beispiel: urn:xoev-de:xta:schutzprofile:fensterbriefumschlag_1.0.1
Hier wird die Kurzbezeichnung des Profils eingetragen (versionsübergreifend). Sie soll nach Möglichkeit aus einem oder zwei Worten bestehen.
Hier ist die vollständige Bezeichnung des Profils (versionsübergreifend) einzutragen. Sie kann aus mehreren Begriffen bestehen.
Unterhalb dieses Element sind die Daten des Herausgebers des Profils eingetragen.
Hier wird die Kurzbezeichnung des Herausgebers eingetragen.
Hier ist die vollständige Bezeichnung des Herausgebers einzutragen.
Grundstruktur für alle Infrastrukturprofile
Dieses Element wird gefüllt mit Informationen zu Identität und Gültigkeit der vorliegenden Profil-Instanz.
Identität und Herkunft der vorliegenden Profil-Instanz (informativ)
Dokumentation der vorliegenden Profil-Instanz
Gültigkeit der vorliegenden Profil-Instanz
Unter diese Kategorie fallen alle Servicequalitäten, die dazu dienen, die Infrastrukturkomponenten für einen Transport festzulegen.
Beschreibt die für einen Transport benötigten bzw. einzusetzenden Verzeichnisdienste und Übertragungswege.
Geltungsbereich für das vorliegende Infrastrukturprofil
Vorgaben zu den möglichen Übertragungskanälen
Kommunikationskanal zwischen Sender und Empfänger (Art der technischen Verbindung oder das Netz, über das kommuniziert wird). Wenn mehrere Kanäle vorgegeben werden, liegt es in der Zuständigkeit der Rolle Sender, die für einen gegebenen Transportauftrag geeignete Vorgabe auszuwählen. Die Auswahl muss im ServiceReport durch das Ereignis AuswahlServicequalitaet protokolliert werden. Wenn keiner der angegebenen Kanäle verwendet werden kann, wurde die Serivcequalität nicht erfüllt.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Vorgaben zum Format der Transportnachrichten
In diesem Element wird das Format eingetragen, in dem die Daten zwischen Sender und Empfänger zu übertragen sind.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Vorgaben zum Transportprotokoll
Dieses Element legt das Übertragungsprotokoll fest, das für die Kommunikaiton der Nachrichten zwischen Sender und Empfänger zu verwenden ist.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Vorgaben zur Adressierung
Hier wird die Bezeichnung des Verzeichnisdienstes eingetragen, der für jeden Teilnehmer des Nachrichtenaustauschs die Parameter für die technische Adressierung von Teilnehmern bereitstellt.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Vorgaben zur Identifizierung
Hier ist der Verzeichnisdienst genannt, der zu allen Teilnehmern die Parameter und Entitäten für Identität und Identitätsnachweis bereitstellt.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Rollenbezogene Vorgaben zum Herausgeber von Zertifikaten
Hier wird die Rolle in der XTA-Infrastruktur (Autor, Sender, ...) benannt, auf die sich die Vorgabe bezieht.
Hier ist eine Vorgabe in Bezug auf den Herausgeber der zugeordneten Zertifikate einzutragen.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Festlegungen zur Protokollführung in Transportprozessen Thema ist hier Vorhaltung und Löschung der Protokollinhalte. Die Qualität der Löschung (wie sie durchzuführen ist) wird an anderer Stelle (im Schutzprofil) geregelt. Diese Festlegungen gelten für alle Transporteure in den Rollen Sender und Empfänger.
Es ist die Anzahl Tage einzutragen, für die die Protokolle mindestens vorzuhalten sind.
Hier ist die Höchstspeicherzeit für ggf. erstellte Protokolle einzutragen. Es ist die Anzahl Tage einzutragen, nach deren Verstreichen die Protokolle spätestens zu löschen sind.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Festlegungen zum Umgang mit Daten - also mit den Fachnachrichten - in einer XTA-Infrastruktur eingetragen. Diese Festlegungen gelten für alle Transporteure in den Rollen Sender und Empfänger.
Generell gilt, dass durch den Sender erfolgreich übermittelte Daten auf Seiten des Senders anschließend zu löschen sind ("erfolgreich übermittelt" bedeutet, dass die Daten im Zugriffsbereich des Empfängers angekommen sind). Dieses Element dient der Festlegung, wann (a) nicht-vermittelte Daten durch den Sender bzw. den Empfänger zu löschen sind und wann (b) vermittelte Daten vom Empfänger zu löschen sind. Es ist in das Element die Höchstspeicherzeit für die vorgehaltenen Daten einzutragen. Es ist die Anzahl Tage einzutragen, nach deren Verstreichen die Daten spätestens zu löschen sind.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Vorgaben zum Infrastrukturknoten, der das Ende des Übertragungsweges der Fachnachricht ist
Knoten der Infrastruktur, an dem die fachliche Nachricht final abzuliefern ist
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Größenbeschränkung für den Payload der Transportnachricht Falls eine Prüfung durchgeführt wird, muss die Auswahl im ServiceReport durch das Ereignis AuswahlServicequalitaet protokolliert werden. Hierbei ist der Name des Elementes und die ermittelte Nachrichtengröße eingetragen werden.
Dieses Element ermöglicht es, eine Größenbeschränkung für den gesamten übergebenen Payload der Transportnachricht festzulegen. Die Größenbeschränkung ist als positive ganze Zahl anzugeben und bezeichnet eine Anzahl Megabyte (MB). Größenbeschränkungen können sich zum Beispiel aus den technischen Grenzen der Fachverfahren und aus den technischen Grenzen der Infrastruktur ergeben.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Typ für die Angabe der Gültigkeit (von, bis) einer Profil-Instanz.
Hier ist, falls eine solche Festlegung vorgesehen ist, der Tag einzutragen, an dem die Gültigkeit der Profil-Instanz beginnt.
Hier ist, falls eine solche Festlegung vorgesehen ist, der letzte Tag der Gültigkeit der Profil-Instanz einzutragen.
Typ für die Identifikation einer Profil-Instanz. Lässt sich sowohl einsetzen, um innerhalb einer Profilinstanz ihre Identität einzutragen als auch für die Referenzierung auf eine Profilnstanz.
Hier wird die Versionsbezeichnung der Profil-Instanz eingetragen. Die Versionsbezeichnung ist aus Zahlen, ggf. kombiniert mit Punkten, zu bilden. Weitere Zeichen (wie z. B. Unterstriche) sind nicht vorgesehen. Beispiel für eine Versionsbezeichnung: 1.1
Hier ist die URI einzutragen, durch die eine Profil-Instanz identifiziert wird. Die Bezeichnung hat die Form einer URN. Dieser Bezeichner wird versionsübergreifend interpretiert, er darf also keine Angabe einer Versionsnummer enthalten. Es sind die Bildungsregeln laut XÖV-Handbuch anzuwenden. Beispiel: urn:xoev-de:xta:schutzprofile:fensterbriefumschlag
Grundstruktur für alle Kryptographieprofile
Dieses Element wird gefüllt mit Informationen zu Identität und Gültigkeit der vorliegenden Profil-Instanz. Hier ist die Versionsnummer der Kryptographieprofil-Instanz einzutragen.
Identität und Herkunft der vorliegenden Profil-Instanz (informativ)
Dokumentation der vorliegenden Profil-Instanz
Gültigkeit der vorliegenden Profil-Instanz
Hier ist das Datum einzutragen, an dem die Kryptographieprofil-Instanz veröffentlicht wurde.
Unterhalb dieses Elements wird der Inhalt des Kryptographieprofils dargestellt. Dies sind die Definitionen der bei der Umsetzung der Anforderungen aus Infrastruktur- und Schutzprofilen zu verwendenden kryptographischen Mittel. Im Zusammenhang wird dies näher erläutert im XTA-Spezifikationsdokument Rahmenbedingungen.
Eine Liste von Nachrichtentypen, die einem gemeinsamen Namensraum (Namespace) zugeordnet sind.
Pro Element ist ein Nachrichtentyp aus dem Fachstandard einzutragen.
Hier ist der Namensraum (Namespace) des Fachstandards in einer bestimmten Version einzutragen, dem die Nachrichtentypen zugeordnet sind.
Grundstruktur für alle Schutzprofile
Dieses Element wird gefüllt mit Informationen zu Identität und Gültigkeit der vorliegenden Profil-Instanz.
Identität und Herkunft der vorliegenden Profil-Instanz (informativ)
Dokumentation der vorliegenden Profil-Instanz
Gültigkeit der vorliegenden Profil-Instanz
In den Bereich der Schutzkategorie sind die Schutzziele des Datenschutzes (siehe XTA-Spezifikationsdokument Rahmenbedingungen) einsortiert, soweit für die XTA Service Profile relevant. Sie sind hier gruppiert unter die Oberbegriffe der Transparenz und der Intervenierbarkeit.
Unter dem Bereich der Sicherheitskategorie stehen die Servicequalitäten der Datensicherheit, soweit für die XTA Service Profile relevant. Sie sind hier zugeordnet den Oberbegriffen Vertraulichkeit und Integrität.
Bei der Erstellung einer Schutzprofil-Instanz für die Servicequalitäten ist jeweils eine Ausprägung und / oder ein Geltungsbereich anzugeben.
Bei Transparenz geht es um Nachvollziehbarkeit. Wenn die Prozesse der Nachrichtenübermittlung transparent ausgestaltet sind, bieten sie Aufsichtsbehörden, dem Auftraggeber oder sonstigen Betroffenen (beispielsweise in den Rollen Autor, Sender, Empfänger, Leser) die Möglichkeit, Vorgehen und Ereignisse nachzuvollziehen bzw. zu überprüfen. Einsehbare Protokolle und zugestellte Quittungen sind das XTA-Angebot, Transparenz zu unterstützen.
Protokolle / Reports gemäß XTA-Vorgaben dokumentieren die Bearbeitungsschritte und die Ergebnisse im Rahmen der Abarbeitung eines Transportauftrags. Sie werden durch die Knoten geführt, die an dieser Abarbeitung beteiligt sind und die entsprechenden Zugriff auf die MessageID des Transportauftrags haben. Dabei bedeutet Protokollierung durch Rolle Autor nicht notwendigerweise, dass dies durch das Fachverfahren geschieht. Diese Aufgabe kann an das Transportverfahren delegiert sein.
Hier ist einzutragen, in Bezug auf welche Rolle in der XTA-Infrastruktur hier Festlegungen zur Protokollierung eingetragen werden soll.
Hier ist einzutragen, ob durch den betreffenden Knoten ein Protokoll / ein Report zu führen ist und mit welchem Absicherungsniveau dies geschehen soll.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Unterhalb dieses Elements wird eingetragen, welche Quittungen in einem bestimmten Kontext gefordert sind. In einer XTA-Infrastruktur ist die Möglichkeit vorgesehen, dass Knoten der Infrastruktur durch Quittungen über entfernte Ereignisse der Abarbeitung eines Transportauftrags informiert werden. (vgl. XTA-Spezifikationsdokument Rahmenbedingungen)
Hier ist eine der Quittungsarten einzutragen, welche in einer XTA-Infrastruktur vorgesehen sind (siehe XTA-Spezifikationsdokument Rahmenbedingungen). Pro Quittungsart, die im Schutzprofil vorgeschrieben werden soll, ist ein eigenes Element zu erstellen.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Wenn ein Verfahren intervenierbar ausgestaltet ist, bietet es der betroffenen Person oder Organisation die Möglichkeit, ihre Rechte in einem definierten Vorgehen kontrolliert zu wahren bzw. durchzusetzen.
Das Löschen der Daten und Protokolle erfolgt mit einer vorgegebenen Qualität, welche hier festgelegt wird. Der Zeitpunkt des Löschens wird an anderer Stelle (im Service Profil) geregelt. Diese Servicequalität ist nicht transportrelevant, da das Löschen der Daten nach dem Transport erfolgt. Dementsprechend muss eine Abweichung von dieser Servicequalität nicht im tr eingetragen werden.
In diesem Element wird die geforderten Ausprägung der Servicequalität Löschen von personen- oder organisationsbezogenen Daten hinterlegt. Aus dieser geht hervor, auf welche Weise diese Daten zum vorgegebenen Zeitpunkt zu löschen sind.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Die Grundstruktur für alle Serviceprofile.
Dieses Element wird gefüllt mit Informationen zu Identität und Gültigkeit der vorliegenden Profil-Instanz. Wenn das Profil nicht mehr gültig ist, darf das Profil nicht angewendet werden. Der Transport muss abgebrochen werden. Die verletzte Vorgabe muss mit dem Ereignis ServiceQualitaetVerletzt im ServiceReport dokumentiert werden. Im TransportReport muss für das nichtanwendbare sp eine Fehlermeldung ParameterIsNotValidException protokolliert werden.
Identität und Herkunft der vorliegenden Profil-Instanz (informativ)
Dokumentation der vorliegenden Profil-Instanz
Gültigkeit der vorliegenden Profil-Instanz
Beschreibt die Eigenschaften eines oder mehrerer fachlicher Dienste, auf die das vorgegebene sp angewendet werden soll. Wird mindestens eine Eigenschaft nicht erfüllt, kann das vorgegeben sp nicht angewendet werden. Der Transport muss abgebrochen werden. Jede Eigenschaft, die nicht erfüllt wurde, muss jeweils durch ein Ereignis ServiceQualitaetVerletzt im ServiceReport dokumentiert werden. Im TransportReport muss für das nichtanwendbare sp eine Fehlermeldung ParameterIsNotValidException protokolliert werden.
Referenz auf eine existierende Schutzprofil-Instanz, die Struktur selbst ist in schutzProfil definiert.
Referenz auf existierende Infrastrukturprofill-Instanz, die Struktur ist in infrastrukturProfil definiert. Wenn mehrere Referenzen angegeben werden, liegt es in der Zuständigkeit der Rolle Sender, das für einen gegebenen Transportauftrag geeignete Infrastrukturprofile aus den referenzierten Infrastrukturprofilen auszuwählen. Die Auswahl muss im ServiceReport durch das Ereignis AuswahlProfil protokolliert werden.
Referenz auf existierende Kryptographieprofil-Instanz, die Struktur ist in kryptographieProfil definiert. Wenn mehrere Referenzen angegeben werden, liegt es in der Zuständigkeit der Rolle Sender, das für einen gegebenen Transportauftrag geeignete Kryptographieprofil aus den referenzierten Kryptographieprofilen auszuwählen. Die Auswahl muss im ServiceReport durch das Ereignis AuswahlProfil protokolliert werden.
Grundstruktur für alle Servicekategorien.
Eindeutige Identifikation eines fachlichen Dienstes, durch eine eindeutige Ressourcenkennung (URI) und zugeordneten fachlichen Nachrichtentypen.
In diesem Element steht bzw. ist einzutragen die Bezeichnung des Service. Es ist jeweils die fachliche Dienst-Bezeichnung einzutragen; sie ist im Fachstandard spezifiziert. Für Fachstandards mit DVDV-Bezug ist diese Bezeichnung die URL der Service-WSDL. Diese muss für Fachstandards im DVDV-Umfeld in der Spezifikation des Fachstandards eingetragen sein.
Unterhalb dieses Elements werden die Gruppen von Nachrichtentypen eingetragen, die zu diesem Dienst (Service) gehören.
Dies ist eine Liste von Nachrichtentypen, die einem gemeinsamen Namespace zugeordnet sind.
Angabe zur Art der fachlichen Kommunikation (synchron oder asynchron)
Festlegung für eine fachliche Kommunikation, ob eine fachliche Antwortnachricht erwartet wird. Für synchrone Szenarien mit Fachantwort ist hier true zu wählen, für asynchrone Szenarien und für synchrone Szenarien ohne Fachantwort false.
Hier wird die für Verfügbarkeit des fachlichen Dienstes zur Bearbeitung von Transportaufträge eingetragen. Diese wirkt sich unmittelbar auf die Anforderung zur Verfügbarkeit der Transportverfahren aus, mit denen diese Verfügbarkeit realisiert wird. Die Verfügbarkeit ist dabei die Wahrscheinlichkeit, dass der Transportauftrag innerhalb des vereinbarten Zeitraums ausgeführt wird.
Die Zustellfrist innerhalb derer der fachliche Dienst die Zustellung von Fachnachrichten und damit die über diesen Dienst erteilten Transportaufträge abschließen muss. Die Zeitspanne beginnt ab dem Zeitpunkt der Erteilung des Transportauftrags.
Unter dem Bereich der Sicherheitskategorie stehen die Servicequalitäten der Datensicherheit, soweit für die XTA Service Profile relevant. Sie sind hier den Oberbegriffen Vertraulichkeit und Integrität zugeordnet. Gegebenenfalls ist bei der Erstellung einer Schutzprofil-Instanz eine Ausprägung (z.B. 'Vertraulichkeit hoch') und / oder ein Geltungsbereich (z.B. 'geltend für die Nachrichtenkommunikation auf der Strecke 'Sender-Empfänger') anzugeben, wofür bei den Unterelementen jeweils die benötigten Codelisten hinterlegt sind.
Die Vertraulichkeit einer Nachricht oder von Daten ist die Eigenschaft, nur für einen abgegrenzten Empfängerkreis vorgesehen zu sein. Diese Servicequalität wird hier definiert bezogen auf einen bestimmten Geltungsbereich der Nachrichtenkommunikation (Element geltungsbereich). Außerdem wird die Anforderung formuliert bezogen auf ein gefordertes Niveau der Vertraulichkeit (Element qualitaet). Wenn mehrere Vorgaben zur Vertraulichkeit festegelegt werden, liegt es in der Zuständigkeit der Rolle Sender, die für einen gegebenen Transportauftrag geeignete Vorgabe unter Berücksichtigung des Geltungsbereichs auszuwählen. Die Auswahl muss im ServiceReport durch das Ereignis AuswahlServicequalitaet protokolliert werden.
Hier ist einzutragen, für welche Teilstrecken der Nachrichtenkommunikation eine Vertraulichkeit gefordert werden soll.
Hier ist einzutragen, welches Niveau von Vertraulichkeit auf der entsprechenden Strecke gefordert ist.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Unter Integrität werden die Unversehrtheit von Daten und das korrekte Funktionieren von Systemen verstanden.
Organisatorische Anforderung an die Erklärung des Betreibers eines Fach- oder Transportverfahrens über seine Verlässlichkeit. Die Erklärung ist an einem definierten Ort zu hinterlegen. Die Einhaltung kann technisch nicht überprüft werden, der Ort, an dem die Erklärung zum Zeitpunkt des Transportes hinterlegt wurde, muss jedoch im sp durch das Ereignis ErklaerungHinterlegt dokumentiert werden.
Organisatorische Anforderung an die Erklärung des Herstellers über die Verlässlichkeit der von ihm vorgelegten Software hins. Betriebs- und Prozessintegrität. Die Erklärung ist an einem definierten Ort zu hinterlegen. Die Einhaltung kann technisch nicht überprüft werden, der Ort, an dem die Erklärung zum Zeitpunkt des Transportes hinterlegt wurde, muss jedoch im sp durch das Ereignis ErklaerungHinterlegt dokumentiert werden.
Die Kommunikationsteilnehmer müssen sich der Identität des Kommunikationspartners vergewissern. In welchem Maß (Element qualitaet) und in welchem Kontext (Element geltungsbereich) das zu geschehen hat: dafür ist die Servicequalität der Authentizität zu definieren. Wenn mehrere Vorgaben zur Authentizität festegelegt werden, liegt es in der Zuständigkeit der Rolle Sender, die für einen gegebenen Transportauftrag geeignete Vorgabe unter Berücksichtigung des Geltungsbereichs auszuwählen. Die Auswahl muss im ServiceReport durch das Ereignis AuswahlServicequalitaet protokolliert werden.
Hier ist einzutragen, für welche Teilstrecken der Nachrichtenkommunikation die Authentizität abzusichern ist.
Hier ist einzutragen, welches Niveau von Authentizität auf der entsprechenden Strecke gefordert ist.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Die Servicequalität der Unveränderbarkeit ist die Anforderung, dass die Daten im Zuge ihrer Übertragung durch die Messaging Infrastruktur nicht verändert werden können. In welchem Maß (Element qualitaet) und in welchem Kontext (Element geltungsbereich) diese Anforderung besteht wird in einer Instanz dieses Typs definiert. Wenn mehrere Vorgaben zur Unveränderbarkeit festegelegt werden, liegt es in der Zuständigkeit der Rolle Sender, die für einen gegebenen Transportauftrag geeignete Vorgabe unter Berücksichtigung des Geltungsbereichs auszuwählen. Die Auswahl muss im ServiceReport durch das Ereignis AuswahlServicequalitaet protokolliert werden.
Hier ist einzutragen, für welche Teilstrecken der Nachrichtenkommunikation die Unveränderbarkeit abzusichern ist.
Hier ist einzutragen, welches Niveau von Unveränderbarkeit auf der entsprechenden Strecke gefordert ist.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Für die durch die Beteiligten zu verwendenden Zertifikate lassen sich hier Vorgaben formulieren, indem das geforderte Zertifikatsniveau und das geforderte Zertifikatsmedium angegeben wird. Zur Quelle der Zertifikate werden die (spezifisch für den Service zu treffenden) Festlegungen nicht hier formulilert, sondern in der Serivcekategorie. Wenn mehrere Vorgaben zu den zu verwendenden Zertifikaten festegelegt werden, liegt es in der Zuständigkeit der Rolle Sender, die für einen gegebenen Transportauftrag geeignete Vorgabe unter Berücksichtigung des Niveaus und des Mediums auszuwählen. Die Auswahl muss im ServiceReport durch das Ereignis AuswahlServicequalitaet protokolliert werden.
Hier ist der Beteiligte in einer XTA-Kommunikationsinfrastruktur zu nennen, in Bezug auf dessen Zertifikate hier Anforderungen definiert werden.
Hier ist das geforderte Nivau der Zertifikate zu benennen.
Hier ist das geforderte Medium der Zertifikate zu benennen.
Hier wird festgelegt was geschehen soll, wenn von der zugehörigen Vorgabe abgewichen wird. Das Abweichverhalten muss aus der vorgegebenen Codeliste gewählt werden.
Dieser Typ bildet eine Algorithmus-Deklaration für Cipher-Suiten ab.
Algorithmus-Deklaration für Digests ohne Erweiterungen.
Algorithmus-Deklaration für Signaturen ohne Erweiterungen.
Algorithmus-Deklaration für symmetrische Verschlüsselung inkl. Schlüsselverschlüsselung.
Hier sind Algorithmen und Parameter zur Schlüsselverschlüsselung aufgeführt.
Algorithmus-Deklaration für asymmetrische Verschlüsselung inkl. Schlüssellänge.
Die Quelle beschreibt die Herkunft des Algorithmus. Hier kann z. B. WS-Security policy Spec oder BSI Algo Catalog stehen.