A_25528 - Kein Bridging

Ein serverseitiges Bridging zu anderen Messaging-Protokollen DARF NICHT vom TI-M FD unterstützt werden. [<=]

A_25641-01 - Matrix Spezifikationsversion

Als Basis MUSS die Matrix Spezifikation in der Version 1.11 verwendet werden. [<=]

A_25304 - Nachnutzung bestehender Authentifizierungsverfahren

Anbieter des TI-Messenger-Dienstes KÖNNEN für die Authentisierung von Akteuren in der Rolle "User" bestehende Authentifizierungsverfahren der Organisation nachnutzen. [<=]

A_25305 - Verantwortung der Organisation bei Nachnutzung bestehender Authentifizierungsverfahren

Werden bestehende Authentifizierungsverfahren der Organisation für die Authentisierung von Akteuren in der Rolle "User" nachgenutzt, MÜSSEN Anbieter die Organisation und die Administratoren explizit darauf hinweisen, dass die Sicherheit der Nutzerauthentisierung damit in die Verantwortung der Organisation gegeben wird.  [<=]

A_25306 - Kontrolle über genutzte Authentifizierungsverfahren

Der Anbieter MUSS sicherstellen, dass Authentifizierungsverfahren, die von einer Organisation für die Authentisierung von Akteuren in der Rolle "User" verwendet werden, unter Kontrolle der Organisation sind und entsprechende Authentisierungsmittel von dieser verwaltet und gesperrt werden können. Selbiges gilt, wenn der Anbieter die Nachnutzung bestehender Authentifizierungsverfahren der Organisation ermöglicht. [<=]

A_25307 - Verwendung von 2FA

Der Anbieter MUSS sicherstellen, dass zur Authentisierung mindestens zwei Faktoren verwendet werden und die Sicherheitsempfehlungen des BSI [BSI 2-Faktor] Berücksichtigung finden. [<=]

A_25308 - Resilienz der 2FA

Als 2. Faktor MUSS ein Verfahren gewählt werden, dass vom BSI hinsichtlich seiner Resilienz gegenüber Angriffen aus der Ferne mindestens mit "mittel" bewertet wurde [BSI 2-Faktor]. [<=]

A_25491 - Bereitstellung von Datenschutzinformationen

Der TI-M Client MUSS für den Akteur klar erkennbar Datenschutzinformationen bereitstellen. [<=]

A_25495 - Anzeige von Fehlern beim Versand

Der TI-M Client MUSS den Nutzer über Fehler beim Versand informieren. [<=]

A_25512 - Trennung von Mandanten

TI-M Clients MÜSSEN verhindern, dass bei geteilten Endgeräten ein Akteur des TI-M Clients auf Daten oder Funktionen eines anderen Akteurs des TI-M Clients auf diesem Gerät zugreifen kann. [<=]

A_25513 - Mandantentrennung nicht durch Betriebssystem

Für den Schutz der Daten verschiedener Mandanten, DARF sich der TI-Messenger Client NICHT darauf verlassen, dass seitens des Betriebssystems eine Trennung von Nutzern vorgenommen wird, welche den Zugriff auf Daten anderer Akteure verhindert, da derartige Funktionalität nicht notwendigerweise genutzt wird. [<=]

A_25519 - Schnittstelle für Virenscanner

TI-M Clients KÖNNEN über Schnittstellen und Funktionen verfügen, mit denen empfangene entschlüsselte Dateien zur Überprüfung auf Schadsoftware an Virenscanner übergeben werden, bevor diese verarbeitet werden. [<=]

A_25520 - Vorgehen bei Meldung von Schadsoftware

Nutzt ein TI-M Client die Möglichkeit zur Prüfung von Inhalten durch einen Virenscanner und meldet dieser Virenscanner das Vorhandensein von Schadsoftware im geprüften Inhalt, SOLL der TI-M Client diesen Inhalt verwerfen. [<=]

A_25521 - Information über Vorgehen bei Meldung von Schadsoftware

Verwirft der TI-M Client Inhalte, MUSS der Akteur darüber sowie über den Grund informiert werden. [<=]

A_25522 - Fehlschlag der Prüfung auf Schadsoftware

Nutzt ein TI-M Client die Möglichkeit zur Prüfung von Inhalten durch einen Virenscanner und meldet dieser Virenscanner ein Fehlschlagen der Prüfung, MUSS der TI-M Client den Akteur über den Prüfstatus und die mögliche Gefahr informieren. [<=]

A_25523 - Keine Ausführung aktiver Inhalte

Verfügt der TI-M Client über eine Funktion, Dokumente direkt über den TI-M Client ohne Nutzung von Third-Party Software anzuzeigen, MUSS er die Ausführung von aktiven Inhalten verhindern. [<=]

A_25524 - Anzeige von Metadaten

Verfügt der TI-M Client über eine Funktion, Dokumente direkt über den TI-M Client ohne Nutzung von Third-Party Software anzuzeigen, MUSS er es ebenfalls ermöglichen, zugehörige Metadaten auch ohne Öffnen oder Herunterladen der Datei selbst einzusehen. [<=]

A_25525 - Information über Gefahren von Schadsoftware

Der TI-M Client MUSS den Akteur darüber informieren, dass Dokumente Schadsoftware enthalten können und welche Maßnahmen der Akteur zum Selbstschutz vornehmen kann. [<=]

A_25569 - Einbringung von Schlüsseln und Token

TI-M Client-Hersteller MÜSSEN sicherstellen, dass Schlüssel und Token sicher in den TI-M Client eingebracht werden, das heißt unter Nutzung der von der Spezifikation und dem Matrix-Protokoll vorgesehenen Abläufe und Verfahren.
In diesem Sinne werden die verschiedenen Token (siehe Tabelle 2) mittels TLS-gesicherter Verbindung zum jeweiligen Fachdienst eingebracht, der diese nach erfolgreichem Handshake ausstellt. Die Einbringung von Schlüsseln folgt den Vorgaben und Funktionen des Matrix-Protokolls (SSSS, Key Sharing, Wiederherstellung aus verschlüsseltem Offline-Backup, Key Agreement, Schlüsselfortschreibung). [<=]

A_25570 - Speicherung von Schlüsseln und Token

TI-M Client-Hersteller MÜSSEN technisch sicherstellen, dass Schlüssel und Token nicht in andere Speicher ausgelagert werden können, als die dafür vorgesehenen Speicher der TI-M Clients oder dem [SSSS] des beteiligten Matrix-Homeservers. [<=]

A_26435 - Ver- und Entschlüsselung

Die Ver- und Entschlüsselung MUSS lokal auf dem TI-M Client erfolgen. [<=]

A_25573 - Verwendung von TLS zur Kommunikation mit dem Fachdienst und VZD-FHIR-Directory

TI-M Clients MÜSSEN mit anderen Komponenten des TI-M Dienstes sowie dem VZD-FHIR-Directory über TLS kommunizieren und die dafür erforderlichen Verfahren unterstützen. Hierzu gelten die Festlegungen der [gemSpec_Krypt]. [<=]

A_25575 - Löschung von Nachrichten

TI-M Clients MÜSSEN über eine nachrichtenbasierte Löschfunktion verfügen, die es Akteuren erlaubt, ihre eigenen Nachrichten gemäß [Client-Server API/#redactions] zu löschen. [<=]

A_25576 - Lokales Löschen bei Entfernung von Nachrichten aus dem Room State

Wurde eine Nachricht durch einen anderen Akteur gemäß [Client-Server API/#redactions] gelöscht, so MÜSSEN TI-M Clients, die sich im selben Raum befinden, die entsprechende Nachricht auch lokal löschen und kennzeichnen. [<=]

A_25577 - Kennzeichnung gelöschter Nachrichten

TI-M Clients MÜSSEN im Rahmen der Kennzeichnung gelöschter Nachrichten den löschenden Akteur, das Datum und die Uhrzeit der Löschung enthalten. [<=]

A_25580 - Sicherheitsrisiken von Software Bibliotheken minimieren

Der TI-M Client MUSS Maßnahmen umsetzen, um die Auswirkung von unentdeckten Schwachstellen in benutzten Software-Bibliotheken zu minimieren. [<=]

A_25584 - Selbst-Update des TI-M Clients aus vertrauenswürdigen Quellen

Lädt und appliziert ein TI-M Client Selbstaktualisierungen, so MUSS er sicherstellen, dass Updates nur von bekannten und vertrauenswürdigen Quellen bezogen werden, nachdem die Authentizität der Quelle technisch erfolgreich verifiziert wurde. [<=]

A_25598 - Einsatz auditierter Verschlüsselung

TI-M Clients MÜSSEN für die Verschlüsselung von Nachrichten eine auditierte und für ausreichend sicher befundene Implementierung von Olm/Megolm verwenden.  [<=]

A_25599 - Verwendung anderer Implementierungen von Olm/Megolm

Sollte für die Umsetzung von Olm/Megolm eine andere Implementierung als eine der von der gematik vorgesehenen genutzt werden, MUSS der Hersteller einen Sicherheitsnachweis erbringen, welcher nach Art, Umfang und Ergebnis den Audits von Vodozemac und libolm entspricht und von nachweislich geeigneten und vom Hersteller unabhängigen Personen erbracht wurde. [<=]

A_25609 - Konfigurierbare Frist zur Erinnerung an Löschung

TI-M Clients MÜSSEN über eine konfigurierbare Frist zur Erinnerung an die Löschung von Räumen und Rauminhalten verfügen, welche die Löschung aller Daten, die älter als die konfigurierte Frist sind, anbietet. [<=]

A_25610 - Voreinstellung zur Erinnerung an Löschung

Die konfigurierbare Frist in TI-M Clients zur Erinnerung an die Löschung von Räumen und Rauminhalten MUSS auf sechs Monate voreingestellt sein und bezieht sich auf den Zeitstempel der Erstellung der letzten Nachricht in einem Raum. [<=]

A_25611 - Durchführung der Löschung

Ist die im TI-M Client konfigurierte Frist zur Erinnerung an die Löschung von Räumen und Rauminhalten verstrichen, so MUSS der Client den Nutzer darauf hinweisen und die Löschung des Raumes und dessen Inhalten empfehlen. Stimmt der Nutzer zu, so wird er aus dem Raum entfernt, was auch zu einer Benachrichtigung des Servers führt. [<=]

A_25501-01 - Sperre des TI-Messenger Clients

Es MUSS sichergestellt sein, dass der Zugriff auf den TI-M Client, der kein Web-Client ist, erst nach Authentisierung gegenüber dem TI-M Client möglich ist. Mit Authentisierung ist die Überwindung einer App-Sperre gemeint. [<=]

A_26023-01 - Mehr-Faktor-Authentisierung für den TI-M Client zzgl. Ersatzverfahren

Der TI-M Client MUSS, da er medizinische Daten lokal zwischenspeichern kann, dem Akteur mindestens eine Authentisierungsart mit mehreren Faktoren für die Überwindung der App-Sperre (des TI-M Clients) anbieten. [<=]

A_25502-01 - Entsperrung per Biometrie

Wird für die Überwindung der App-Sperre zum Zugriff auf den TI-M Client das Mittel Biometrie als möglicher Faktor für die Authentisierung angeboten, MUSS es den Vorgaben aus [gemSpec_IDP_Sek], Kapitel 4.3.2.2 ("Nutzung von Biometrie") genügen. [<=]

A_26024 - Hinweise zu Authentisierungsarten

Der TI-M Client SOLL dem Akteur die verfügbaren Authentisierungsarten in verständlicher Form darstellen und erklärende Hinweise zur Verfügung stellen. [<=]

A_25503-01 - Notwendigkeit der Entsperrung

Die Überwindung der Sperre zum Zugriff auf den TI-M Client MUSS unter folgenden Bedingungen gefordert werden:

• nach jedem Start der Anwendung,  
• nach jedem Benutzerwechsel am Betriebssystem, 
• jedes Mal, wenn die App (auf einem Mobilgerät) in den Zustand „aktiv“ wechselt, 
• oder spätestens nach einem konfigurierbaren Inaktivitätsintervall

A_26512 - Inaktivitätsintervall für die Notwendigkeit der Entsperrung

Das Inaktivitätsintervall, nach dem erneut eine Entsperrung des TI-M Clients notwendig ist, MUSS konfigurierbar sein und als default auf 5 Min konfiguriert sein. [<=]

A_26446 - Wechsel auf stärkeres Authentisierungsverfahren

Hat der Akteur ein niederschwelliges Verfahren zur Überwindung der App-Sperre gewählt, MUSS der TI-M Client dem Akteur jederzeit die Möglichkeit bieten, wieder auf ein stärkeres Verfahren zu wechseln. [<=]

A_26227 - Längenbegrenzung von Annotationen in Reactions

Der TI-M Client MUSS sicherstellen, dass der Wert des Attributes key im Event-Content in Events des Typs m.reaction beim Erzeugen die Länge eines einzelnen Unicode-Characters bzw. dessen Code Point Repräsentation
nicht überschreitet. [<=]

A_25472 - Nutzer Sessions Anzeige

Der Org-Admin-Client MUSS aktive und inaktive Sessions der Devices anzeigen, von denen sich ein Akteur angemeldet hat. [<=]

A_25473 - Akteur abmelden

Der Org-Admin-Client MUSS dem Org-Admin die Möglichkeit bieten die Access-Token & Refresh-Token der einzelnen Devices oder aller Devices zu invalidieren, um den Akteur abzumelden. [<=]

A_25474 - Infomeldungen

Der Org-Admin-Client MUSS das Senden von Informationen/Systemmeldungen an die an einem Messenger-Service angemeldeten TI-M Clients ermöglichen. [<=]

A_26394 - Administration von Benutzeraccounts

Der Org-Admin-Client MUSS folgende Verwaltungsaktionen, bezogen auf die Nutzer von Messenger-Services, die durch die eigene Organisation verwaltet werden, unterstützen:

• Auflisten der Gesamtmenge dieser Nutzer
• Direktes oder indirektes (provisioniertes) Anlegen eines Nutzers
• Löschen oder dauerhaftes Deaktivieren eines Nutzers
• Zurücksetzen der Login Credentials

A_26395 - Administration von Geräten

Der Org-Admin-Client MUSS folgende Verwaltungsaktionen, bezogen auf die Nutzer von Messenger-Services und deren Geräte, die durch die eigene Organisation verwaltet werden, unterstützen:

• Anzeigen aller Geräte bzw. Gerätebindungen eines Nutzers
• Löschen von Geräten und deren Nutzerzuordnung

A_26396 - Org-Admin Authentisierung und Rollenwechsel

Der TI-M Client MUSS zur Erlangung der Rolle "Org-Admin" eine Authentisierung des Akteurs für diese Rolle erzwingen. Dieses gilt auch für einen Wechsel in diese Rolle aus einer bestehenden anderen Rolle. [<=]

A_25601 - Separate Benutzeroberflächen für Administration und Kommunikation

TI-M Clients, die sowohl als Client für die Kommunikation, als auch als Org-Admin-Client genutzt werden, MÜSSEN zur Bereitstellung der Funktionalitäten für die jeweilige Rolle separate User-Interfaces verwenden, welche die für den jeweiligen Zweck relevanten Informationen anzeigen und Funktionen bereitstellen.  [<=]

A_25492 - Löschfunktion des Clients

Der TI-M Client MUSS Löschfunktionen implementieren, die es dem Akteur ermöglichen, Daten sowohl lokal auf dem Client zu löschen, bspw. durch Verlassen eines Raumes, bei dem der gesamte Raum samt Inhalt vom Client entfernt wird, als auch server-seitig, wenn es sich dabei um Daten handelt, die der Nutzer selbst eingebracht hat, bspw. indem er eine von ihm verfasste Nachricht in einem Chat-Raum löscht ("redact"). [<=]

A_25398-01 - QR-Code erstellen

Der TI-M Client für mobile Szenarien MUSS eine Funktion bereitstellen, 2D-Barcodes zu erstellen und diese auf dem Display des Endgerätes anzuzeigen. Hierbei MUSS der 2D-Code in eine QR-Code-Darstellung gemäß ISO/IEC 18004:2006 kodiert werden. Als Inhalt für die Generierung des 2D-Codes MÜSSEN mindestens die Felder des folgenden vCard-Objektes verwendet werden:

A_25422-01 - QR-Code verarbeiten

Der TI-M Client für mobile Szenarien MUSS eine Funktion bereitstellen, die es dem Akteur erlaubt, über die Kamera des Endgerätes einen 2D-Barcode (in einer QR-Code-Darstellung) einzuscannen. Der TI-Messenger MUSS den eingescannten 2D-Code gemäß ISO/IEC 18004:2006 decodieren und mindestens den Inhalt aus den Parametern FN und IMPP dem Akteur anzeigen, damit dieser die Daten in seine Kontaktliste übernehmen kann. [<=]

A_25496 - Keine dauerhafte Standortdatenerhebung

Der TI-M Client DARF Standortdaten NICHT dauerhaft erheben. [<=]

A_25500 - Auslösung der Standorterhebung

Bei der Erhebung von Standortdaten MUSS sichergestellt sein, dass diese Erhebung ausschließlich durch einen menschlichen Benutzer ausgelöst wird und nach Beendigung des Anwendungsfalls, der die Standortdaten erhebt, diese wieder aus dem TI-M Client-Kontext gelöscht werden. [<=]

A_25527 - Prüfung der Geräteintegrität

TI-M Clients für mobile Plattformen MÜSSEN prüfen, ob ein Rooting des Gerätes vorliegt. Ist dies der Fall, MUSS dem Nutzer eine Warnung angezeigt werden und der Versand von Anhängen verhindert werden. [<=]

A_25535 - Abschottung von Inhalten auf mobilen Plattformen

TI-M Clients für mobile Plattformen MÜSSEN sicherstellen, dass Daten, die lokal durch den TI-M Client selbst gespeichert und nicht explizit durch den Nutzer für die Verwendung in anderen Kontexten exportiert wurden, in einem geschützten Speicherbereich auf dem Endgerät abgelegt werden. Hierzu genügen die von mobilen Betriebssystemen üblicherweise zur Verfügung gestellten Mechanismen wie die Verschlüsselung des Dateisystems und die Kapselung von Anwendungen untereinander. [<=]

A_25579 - Schutz gegen OWASP Mobile Top 10 Risiken

Hersteller von TI-M Clients für mobile Szenarien MÜSSEN für die von ihnen angebotenen mobilen TI-M Clients gewährleisten, dass der Client resistent bezüglich der im aktuellen und den beiden vorherigen OWASP Mobile Top 10 Report(s) ausgewiesenen Risiken ist. [<=]

A_25497 - Schutz gespeicherter Daten in Desktop-Clients

Handelt es sich bei dem TI-M Client um eine Desktop-Applikation, MUSS dieser für empfangene und gesendete Daten, die nicht explizit durch den Nutzer für die Verwendung in anderen Kontexten exportiert wurden, gewährleisten, dass diese im Falle der Speicherung auch nur durch den TI-M Client und nach Authentifizierung des jeweiligen Nutzers gelesen werden können. [<=]

A_25396 - Client-Server API

TI-M Clients MÜSSEN die clientspezifischen Anteile der Matrix Client-Server API gemäß [Client-Server API] umsetzen. [<=]

A_25345 - Appendices TI-M Clients

TI-M Clients MÜSSEN die [Matrix Appendices] gemäß der Matrix-Spezifikationen umsetzen. [<=]

A_25395-01 - Matrix Module

Die folgende Tabelle listet die Module aus der Matrix Spezifikation und die Neudefinition der Vorgaben.

Tabelle 3: Matrix Module

A_25397 - create Room

Der TI-M Client MUSS sicherstellen, dass im createRoom-Event maximal die Einladung einer MXID enthalten ist.  [<=]

A_25323 - Anlegen von Räumen

Der TI-M Client MUSS beim Anlegen eines Raumes als Default einen nicht öffentlichen und verschlüsselten Raum anbieten. [<=]

A_25324 - Verschlüsselung von Räumen

Der TI-M Client DARF dem Akteur beim Anlegen privater Räume NICHT erlauben, die Verschlüsselung zu deaktivieren. [<=]

A_25559 - Unterstützung von Olm und Megolm

TI-M Clients MÜSSEN eine Ende-zu-Ende-Verschlüsselung auf Basis von Olm und Megolm unterstützen und dafür der Matrix-Spezifikation gemäß [Client-Server API/#end-to-end-encryption] folgen. [<=]

A_25561 - Hinweis auf unverschlüsselte Kommunikation

Der TI-M Client MUSS Räume, in denen unverschlüsselt kommuniziert wird, durch geeignete UI-Elemente als solche kennzeichnen, sodass der Akteur sich dessen gewahr ist. [<=]

A_25562 - Hinweis auf Öffentlichkeit eines Raums

Der TI-M Client MUSS öffentliche Räume durch geeignete UI-Elemente als solche kennzeichnen, sodass der Nutzer sich der Öffentlichkeit des Raums gewahr ist. [<=]

A_26514 - Mathematical Messages

TI-M Clients DÜRFEN LaTeX-basierte mathematische Ausdrücke¹ NICHT unterstützen.
¹ [Client-Server API/#mathematical-messages] [<=]

A_25517 - Größe versendeter Inhalte

TI-M Clients MÜSSEN in der Lage sein, Dateien mit einer Größe von mindestens 100 MB zu versenden. [<=]

A_25518 - Beschränkung der Größe versendeter Inhalte

TI-M Clients MÜSSEN die in m.upload.size definierte Größenbeschränkung zu versendender Inhalte berücksichtigen. [<=]

A_25557 - Device Verification, Cross-Signing und SSSS für TI-Messenger Clients

TI-M Clients MÜSSEN die Funktionen Cross-Signing und Secure Secret Storage and Sharing ([SSSS]) zur Device Verification unterstützen und dafür der Matrix-Spezifikation gemäß [Client-Server API/#sharing-keys-between-devices] folgen. [<=]

A_26196 - Unterstützung von hkdf-hmac-sha256

TI-M Clients MÜSSEN für die Device Verification das MAC-Verfahren hkdf-hmac-sha256 unterstützen und beim Start der Verification zusätzlich zu hkdf-hmac-sha256.v2 anbieten¹.
¹ [Client-Server API/#mac-calculation] [<=]

A_25394 - Anforderung von refresh token durch den TI-M Client

Der TI-M Client MUSS bei Aufruf der [Client-Server API] Endpoints /register und /login den Parameter refresh_token mit dem Wert true benutzen. [<=]

A_25458 - Verwendung von refresh token

Der TI-M Client MUSS einen nicht mehr gültigen access_token durch Verwendung des refresh_token erneuern. [<=]

A_25399 - Displaynamen anpassen

Das Editieren des Displayname eines Akteurs in der Rolle "User" DARF NICHT durch den Akteur selbst möglich sein. [<=]

A_25431 - Eingabebenachrichtigungen

Eingabebenachrichtigungen MÜSSEN an- und abschaltbar sein und MÜSSEN gemäß Privacy-by-default (Art. 25 Abs. 2 DSGVO) standardmäßig deaktiviert sein. [<=]

A_25436 - Präsenzanzeige

Die Präsenzanzeige MUSS an- und abschaltbar sein und MUSS gemäß Privacy-by-default (Art. 25 Abs. 2 DSGVO) standardmäßig deaktiviert sein. [<=]

A_25433-01 - Konfiguration von Public Read Receipts

TI-M Clients MÜSSEN dem Nutzer erlauben, das Senden öffentlicher Lesebestätigungen (m.read) an- und abzuschalten. [<=]

A_26220 - Defaulteinstellung für Public Read Receipts

TI-M Clients MÜSSEN das Senden öffentlicher Lesebestätigungen standardmäßig deaktivieren ("Privacy by Default" gemäß Art. 25 Abs. 2 DSGVO). [<=]

A_26221 - Private Read Receipts

TI-M Clients MÜSSEN private Lesebestätigungen (m.read.private) versenden, sofern das Senden öffentlicher Lesebestätigungen deaktiviert ist. [<=]

A_25437 - Erwähnungen

TI-M Clients MÜSSEN es ermöglichen, dass über das Eingabefeld andere Raumteilnehmer gemäß [Client-Server API/#user-and-room-mentions] im jeweiligen Chatraum erwähnt werden können. Dazu MUSS der TI-M Client eine entsprechende Nutzerliste anzeigen, sobald der Nutzer ein neues Wort mit "@" startet. [<=]

A_26249 - Historie von Event Replacements

TI-M Clients MÜSSEN eine leicht erreichbare Funktion zur Anzeige der Änderungshistorie von Nachrichten, die durch m.replace-Relationen ersetzt wurden, anbieten. [<=]

A_26261 - Eindeutige Darstellung von Event Replacements

TI-M Clients MÜSSEN Nachrichten, die durch m.replace-Relationen ersetzt wurden, optisch eindeutig kennzeichnen, damit dem Nutzer die Ersetzung offensichtlich wird. [<=]

A_25481 - Raum Historie

Als Default-Einstellung MUSS beim Anlegen eines Raumes die Sichtbarkeit für die Raum-Historie ab dem Zeitpunkt der Einladung ("invited") zu einem Chatraum definiert sein. [<=]

A_25423 - Retry and Order

Das unter [Client-Server API/#recommendations-when-sending-messages] beschriebene Verhalten für das Retry und die Order auf Clientseite ist mit MUSS und nicht mit SHOULD zu implementieren. [<=]

A_25514 - Key-Sharing zwischen Geräten eines Akteurs

TI-M Clients MÜSSEN sicherstellen, dass das Key-Sharing zwischen Geräten desselben Akteurs nur verifizierte Geräte umfasst. Geräte, die im Namen eines bestimmten Akteurs angemeldet, aber nicht verifiziert sind, sind vom Key-Sharing ausgeschlossen. [<=]

A_25430 - Barrierefreiheit

Hersteller eines TI-M Clients SOLLEN die in [ISO 9241] aufgeführten Qualitätsrichtlinien zur Sicherstellung der Ergonomie interaktiver Systeme und Anforderungen aus der Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz (Barrierefreie-Informationstechnik-Verordnung – [BITV 2.0]) beachten. [<=]

A_26193 - Verbot der Push Rule Actions dont_notify und coalesce

Beim Anlegen oder Editieren von Push Rules DÜRFEN TI-M Clients die Actions dont_notify und coalesce NICHT verwenden. [<=]

A_26262 - Authenticated Media am Client

TI-M Clients MÜSSEN anstelle der Endpunkte

• GET /_matrix/media/v3/config
• GET /_matrix/media/v3/download/{serverName}/{mediaId}
• GET /_matrix/media/v3/download/{serverName}/{mediaId}/{fileName}
• GET /_matrix/media/v3/thumbnail/{serverName}/{mediaId}

• GET /_matrix/client/v1/media/config
• GET /_matrix/client/v1/media/download/{serverName}/{mediaId}
• GET /_matrix/client/v1/media/download/{serverName}/{mediaId}/{fileName}
• GET /_matrix/client/v1/media/thumbnail/{serverName}/{mediaId}

A_26268 - Verwendung des Request Headers für Matrix-ACCESS-TOKEN

TI-M Clients MÜSSEN ihr access_token (Token-Art: Matrix-ACCESS-TOKEN) ausschließlich im Authorization Request Header senden. [<=]

A_26574 - Entschlüsseln von Nachrichten nach Wiederanmeldung

TI-M Clients und Fachdienste MÜSSEN es Akteuren ermöglichen Nachrichten, die gesendet wurden nachdem der Akteur vollständig abgemeldet wurde, nach erneuter Anmeldung zu entschlüsseln. [<=]

A_26575 - Ablage von Schlüsseln zum Entschlüsseln von Nachrichten nach Wiederanmeldung

TI-M Clients MÜSSEN Schlüsselmaterial, das zum Entschlüsseln von Nachrichten nach Wiederanmeldung benötigt wird, wie in [SSSS] beschrieben speichern. [<=]

A_25483 - TI-M Client User-Agent

Der TI-M Client für Akteure und der Org-Admin-Client MÜSSEN folgende User-Agent-Kennung bei jedem Verbindungsaufbau zum TI-M FD übermitteln:

X-TIM-User-Agent: $ua-client_id, $ua-OSv [<=]

A_25424 - Archivierung in Archivsysteme

Der TI-M Client MUSS sicherstellen, dass Chatverläufe aus dem TI-M Client extrahiert werden können, damit diese beispielweise in Archivsysteme überführt werden können. Die gematik macht keine Vorgaben, wie die Archivierung zu gestalten ist, da sowohl die Art der Archivierung als auch die anzubindenden Systeme stark variieren. [<=]

A_25585 - Verbot von Werbe-Tracking

Der TI-M Client DARF NICHT Werbe-Tracking verwenden. [<=]

A_25587 - Keine Auswertung durch Dritte

Der datenschutzrechtlich Verantwortliche für die TI-M Clients MUSS die Verarbeitung und Auswertung etwaiger gesammelter Tracking- und/oder Reporting-Daten der TI-M Clients selbst durchführen und DARF die Verarbeitung und Auswertung NICHT von einem Drittanbieter durchführen lassen. [<=]

A_25589 - Einschränkung der Art übermittelter Informationen

Der TI-M Client MUSS, falls er Tracking- und/oder Reporting-Funktionen ohne Einwilligung des Akteurs nutzt, sicherstellen, dass die übermittelten Informationen 

• sich nur auf Clientnutzung (von der ersten Interaktion des Nutzers mit dem Client bis zum Schließen des Clients bzw. bis zum Inaktivitätstimeout) beziehen und nicht mit anderen Clientnutzungen des Akteurs verknüpft werden,
• über die unweigerlich anfallenden Verbindungsdaten hinaus weder personenbezogene noch pseudonymisierte personenbezogene Daten enthalten,
• keine nutzerbezogenen IDs oder gerätespezifischen IDs der Nutzergeräte enthalten,
• keinen Rückschluss auf Versicherte, deren Vertreter, Leistungserbringer oder Kostenträger ermöglichen, insbesondere Rückschlüsse anhand des Nutzerverhaltens über die Zeit oder über Clientnutzungen hinweg,
• nicht durch die Verknüpfung mit personenbezogenen Daten aus anderen Quellen de-anonymisiert werden können

A_25590 - Information über Tracking und Reporting

Der TI-M Client MUSS, falls er Tracking- und/oder Reporting-Funktionen ohne Einwilligung des Akteurs nutzt, den Akteur über das Tracking und/oder Reporting im TI-M Client in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache informieren, bevor die Informationen erhoben werden. [<=]

A_25591 - Zufällige Nutzungs-Identifier

Der TI-M Client MUSS, falls er Tracking- und/oder Reporting-Funktionen ohne Einwilligung des Akteurs nutzt, für jede Clientnutzung neue Nutzungs-Identifier zufällig generieren. [<=]

A_25592 - Neugenerierung zufälliger Nutzungs-Identifier

Der Akteur MUSS jederzeit in der Lage sein, die Neugenerierung von Nutzungs-Identifiern, die vom TI-M Client im Rahmen von Tracking- und/oder Reporting-Funktionen genutzt werden, zu erzwingen. [<=]

A_25593 - Opt-In für Verknüpfung von Informationen

Der TI-M Client MUSS, falls er Tracking- und/oder Reporting-Funktionen mit Verknüpfung der Informationen mehrerer Clientnutzungen implementiert, technisch sicherstellen, dass diese Tracking- und/oder Reporting-Funktionen bei der Installation des TI-M Clients standardmäßig deaktiviert sind und nur nach expliziter Einwilligung durch den Akteur aktiviert werden (Opt-in). Die Ablehnung der Nutzung solcher Funktionen darf die Standardfunktionen des TI-M Clients nicht einschränken. Eine Umgehung des Opt-In unter Verweis auf AGBs oder Nutzungsbedingungen ist nicht zulässig. [<=]

A_25594 - Zweck von Tracking und Reporting

Falls der TI-M Client Tracking- und/oder Reporting-Funktionen implementiert, die erst nach expliziter Einwilligung aktiviert werden (Opt-In), MUSS der TI-M Client dem Akteur vor der Einwilligung in die Aktivierung dieser Funktionen in verständlicher und leicht zugänglicher Form sowie in einer klaren und einfachen Sprache folgende Einwilligungsinformationen anzeigen: 

• welche Daten durch die Tracking-Funktionen erhoben werden,
• zu welchen Zwecken die Daten erhoben werden,
• welche Informationen durch die Auswertung der erhobenen Daten gewonnen werden und ob Rückschlüsse auf den Gesundheitszustand des Akteurs möglich wären,
• wer die Empfänger der Daten sind,
• wie lange die Daten gespeichert werden.

A_25595 - Deaktivierbarkeit zuvor aktivierten Trackings und Reportings

Falls der TI-M Client Tracking- und/oder Reporting-Funktionen implementiert, MÜSSEN diese jederzeit durch den Akteur deaktivierbar sein. [<=]

A_26001 - Information über die Deaktivierbarkeit des Trackings

Der TI-M Client MUSS den Akteur in klarer und einfacher Sprache über die Möglichkeit der Deaktivierung von Tracking und Reporting informieren. [<=]

A_25596 - Kein wiederholtes Erfragen der Einwilligung

Der TI-M Client DARF NICHT wiederholt beim Akteur anfragen um diesen durch Belästigung zu einer Einwilligung in die Nutzung von Tracking- und/oder Reporting-Funktionen zu nötigen. Nach einmaliger Ablehnung erfolgt die erneute Anzeige des zugehörigen Dialogs nur auf Veranlassung durch den Akteur. [<=]

A_26077 - Server-seitiges Schlüssel-Backup

Der TI-M Client MUSS die für die Nutzung des serverseitigen Schlüssel-Backups [Client-Server API/#server-side-key-backups] benötigte Funktionalität implementieren und dem Akteur zur Verwendung anbieten.  [<=]

A_25613 - Hinweis bei passwort-basiertem Schlüssel-Backup

Bietet der TI-M Client für den Schutz von kryptographischem Material (im Rahmen des Schlüssel-Backups) die Verwendung von Passwörtern an, um den Schlüssel für das Schlüssel-Backup zu verschlüsseln, so MUSS er den Nutzer zum Zeitpunkt der Passwortvergabe explizit darauf hinweisen, dass sich das zu vergebene Passwort zwingend von dem Passwort für das Nutzerkonto am Matrix-Homeserver unterscheiden muss, weil sonst die Ende-zu-Ende-Verschlüsselung wenigstens gegenüber dem Homeserver und jenen Akteuren, die diesen kontrollieren, nicht mehr wirksam ist. [<=]

A_25614-01 - Vorschlag von Passwörtern für das Schlüssel-Backup

Der TI-M Client MUSS dem Nutzer im Rahmen der Passwortvergabe ein Passwort vorschlagen, dessen Entropie mindestens gleichwertig ist zu einer zufälligen Kombination von 14 Zeichen, die sich aus Zahlen, Sonderzeichen, sowie Groß- und Kleinbuchstaben zusammensetzt. [<=]

A_25615 - Quelle des Zufalls für Vorschläge

Die Quelle für Zufall, die der TI-M Client zum Vorschlagen von Passwörtern verwendet, MUSS wenigstens die Güte haben, wie jene Quellen, die er im Rahmen der Aushandlung von Schlüsselmaterial für die Kommunikation benutzt. [<=]

A_25616 - Parameter für die passwort-basierte Schlüsselableitung

Bei der passwort-basierten Schlüsselableitung (PBKDF2) im Rahmen des Schlüssel-Backups MUSS der TI-M Client gemäß [OWASP PBKDF2] >= 210.000 Iterationen wählen; die Hash-Funktion ist mit SHA-512 durch die Matrix-Spezifikation vorgegeben. [<=]

A_25618 - Nutzung von Passphrasen

Schlägt der TI-M Client nicht Passwörter, sondern Passphrasen vor, so MUSS die Länge der Phrasen so weit erhöht werden, dass eine vergleichbare Entropie wie bei der Verwendung von Passwörtern nach A_25614 erreicht wird. [<=]

A_25479 - Search Token

Der TI-M Client MUSS dem Akteur einen search-accesstoken für die Suche im VZD-FHIR-Directory bereitstellen. [<=]

A_25428 - VZD-FHIR-Directory Inhalte

Der TI-M Client MUSS eine Funktion bereitstellen, damit Akteure das VZD-FHIR-Directory nach Ressourcen durchsuchen und die Ergebnisse inklusive Detailinformationen anzeigen können. [<=]

A_25363 - Testtreiber-Modul

Für jeden TI-M Client MUSS für die Zulassung ein Testtreiber Modul bereitgestellt werden, welches die von der gematik vorgegebene Schnittstelle [api-Testtreiber] anbietet. [<=]

A_25360 - kein Testtreiber in der produktiven Anwendung

Der Einsatz des Testtreiber-Moduls ist auf das Zulassungsverfahren in Test-Apps beschränkt und DARF NICHT in produktiven Wirkbetriebs-Apps genutzt werden. [<=]

A_25361-01 - Keine Modifikation der Inhalte

Das Testtreiber-Modul DARF die ausgegebenen Inhalte des TI-M Clients NICHT verfälschen und keine Fachlogik des Clients umsetzen. [<=]

A_26228 - Längenbegrenzung von Annotationen in Reactions

Der TI-M FD MUSS sicherstellen, dass Events des Typs m.reaction, deren Wert des Attributes key im Event-Content in Events die Länge eines einzelnen Unicode-Characters bzw. dessen Code Point Repräsentation überschreitet, mit dem Response Code 400 und dem Error Code M_BAD_JSON abgewiesen werden. [<=]

A_26436 - Bereitstellung im Internet

Die Schnittstelle I_Registration bzw. das auf der Schnittstelle aufbauende Frontend SOLL für Organisationen, die einen TI-Messenger erwerben wollen, im Internet angeboten werden. [<=]

A_25354 - Registrierung einer Organisation

Für die initiale Registrierung einer Organisation, MUSS der TI-Messenger-Anbieter die Identität der Organisation mittels SM(C)-B feststellen. [<=]

A_25357 - Verfahren zum Nachweis der Identität einer Organisation

TI-Messenger-Anbieter MÜSSEN für die Feststellung der Identität einer Organisation im Rahmen deren Registrierung wenigstens eines der beiden folgenden Verfahren unterstützen:

• OpenID Connect-Verfahren mit SM(C)-B
  
• KIM-Verfahren

A_25359 - Authorization Code Flow mit PKCE

Der TI-Messenger-Anbieter MUSS sicherstellen, dass bei Verwendung des OpenID Connect-Verfahrens der Authorization Code Flow mit PKCE zum Einsatz kommt. [<=]

A_25362 - Durchführung der PKCE-Challenge

Bei Verwendung des OpenID Connect-Verfahrens, MUSS der Registrierungs-Dienst den PKCE-Code erzeugen und später den Verifier dieser Challenge zusammen mit dem Authorization Code beim zentralen IDP-Dienst gegen ein ID_TOKEN einlösen. [<=]

A_25364 - Validierung von ID_TOKEN

Der Registrierungs-Dienst MUSS das durch den zentralen IDP-Dienst ausgestellte ID_TOKEN validieren und die darin enthaltene ProfessionOID gegen die in der Tabelle "Tab_PKI_403-x OID-Festlegung Institutionen im X.509-Zertifikat der SMC-B" gelisteten OIDs gemäß [gemSpec_OID] prüfen. [<=]

A_25365 - Registrierung am IDP

Registrierungs-Dienste MÜSSEN am zentralen IDP-Dienst gemäß [gemSpec_IDP_FD] registriert sein und den von diesem IDP-Dienst ausgestellten ID_TOKEN vertrauen. [<=]

A_25366 - Claims in ID_TOKEN für Organisationen

Der Anbieter des TI-Messengers MUSS über einen organisatorischen Prozess beim zentralen IDP-Dienst folgende Claims für ID_TOKEN, die auf Basis der Authentisierung mittels SM(C)-B ausgestellt werden, vereinbaren:

• ProfessionOID
• idNummer
• organizationName
• acr
• aud

A_25369 - Prüfung der KIM-Adresse

Bietet der TI-Messenger-Anbieter das KIM-Verfahren an und entscheidet sich die Organisation, deren Identität festgestellt werden soll, dieses Verfahren zu nutzen, MUSS der TI-Messenger-Anbieter die ProfessionOID sowie die TelematikID für die von der Organisation mitgeteilte KIM-Adresse durch Abfrage am LDAP-VZD ermitteln und die ProfessionOID gegen die in der Tabelle "Tab_PKI_403-x OID-Festlegung Institutionen im X.509-Zertifikat der SMC-B" gelisteten OIDs gemäß [gemSpec_OID] prüfen. [<=]

A_25373 - Versand der KIM-Nachricht nach erfolgreicher Prüfung

War die Prüfung der KIM-Adresse hinsichtlich zugehöriger ProfessionOID und TelematikID, welche im Rahmen des KIM-Verfahrens durchgeführt wird, erfolgreich, MUSS der TI-Messenger-Anbieter eine KIM-Nachricht an die angegebene KIM-Adresse senden, welche eine URL enthält, die zurück in den Registrierungsprozess leitet. [<=]

A_25374 - Information zum Zweck der KIM-Nachricht

Versendet der TI-Messenger-Anbieter im Rahmen des KIM-Verfahrens eine KIM-Nachricht zur Fortführung des Registrierungsprozesses, MUSS er den Registrierenden über den Versand der KIM-Nachricht informieren und ihn dazu auffordern den Anweisungen innerhalb der KIM-Nachricht zu folgen. [<=]

A_25377 - Verifikation des Registrierenden

Um sicherzustellen, dass derjenige, der die KIM-Nachricht empfängt und die enthaltene URL aufruft auch der Registrierende ist, MUSS der Registrierungs-Dienst in dem Prozessschritt, der zum Versand der KIM-Nachricht führt, einen zufälligen sechsstelligen Code anzeigen, welcher innerhalb einer Eingabemaske nach Aufruf der URL vom Registrierenden einzugeben ist. [<=]

A_25375 - Form der KIM-Nachricht

Die vom TI-Messenger-Anbieter versendete KIM-Nachricht zur Fortführung des Registrierungsprozesses MUSS kenntlich machen, dass es sich hierbei um eine Authentifizierungsmail handelt und das E-Mail-Header Element X-KIM-Dienstkennung: Auth;Verification;V1.0 enthalten. [<=]

A_25376 - Form der URL innerhalb der KIM-Nachricht

Um das Erraten der URL zu verhindern, MUSS der TI-Messenger-Anbieter sicherstellen, dass die URL innerhalb der KIM-Nachricht, die den Registrierenden zurück in den Registrierungsprozess führt, aus dem FQDN des Registrierungs-Dienstes und einer eindeutigen ID (UUID) gemäß [RFC4122] besteht. [<=]

A_25309 - Authentisierung mittels SM(C)-B

Für Akteure in der Rolle "Org-Admin" MUSS der Registrierungs-Dienst sicherstellen, dass mindestens eine Authentisierung mittels SM(C)-B unterstützt wird.  [<=]

A_25370 - Anlegen eines Org-Admin-Kontos

Konnte die Identität einer sich registrierenden Organisation bestätigt werden, MUSS der Registrierungs-Dienst des TI-Messenger-Anbieters ein Org-Admin-Konto für diese Organisation anlegen und in diesem Konto die ProfessionOID sowie die TelematikID der Organisation für den Org-Admin unveränderlich speichern. [<=]

A_25356 - Registrierung von TI-M Diensten

Der TI-Messenger-Anbieter MUSS sicherstellen, dass Registrierungen von TI-M Diensten nur durch einen authentifizierten Org-Admin durchgeführt werden können und auch nur für die jeweilige Organisation, der er - der Org-Admin - gemäß initialer Registrierung der Organisation angehört. [<=]

A_25628 - Bereitstellung von Messenger-Services

Der Org-Admin MUSS über das Frontend des Registrierungs-Dienstes neue Messenger-Services anlegen und diesen Domains zuweisen können. [<=]

A_25708 - I_Admin Zugriff

Der Registrierung-Dienst MUSS sicherstellen, dass ein Akteur in der Rolle "Org-Admin" über die Schnittstelle I_Admin nur Zugriff auf die Messenger-Services erhält, die er sich über den Anwendungsfall AF_10060-03 - Bereitstellung eines Messenger-Service für eine Organisation. [<=]

A_25607 - I_internVerification

Der Registierungs-Dienst MUSS den Messenger-Proxies eine Schnittstelle für die Bereitstellung der Föderationsliste zur Verfügung stellen. [<=]

A_25625 - Registrierungs-Dienst VZD Provider Login

Der Registrierungs-Dienst MUSS die 2-stufige Anmeldung am VZD-FHIR-Directory für die tim-provider-services Schnittstelle unterstützen. [<=]

A_25626 - TI-M Provider Services

Der Registrierungs-Dienst MUSS die an der Schnittstelle I_VZD_TIM_Provider_Services angebotenen Funktionen, den Messenger-Proxies und dem Frontend des Registrierungs-Dienstes zur Verfügung stellen. [<=]

A_25378 - Forward- und Reverse-Proxy

Der Messenger-Proxy MUSS für jeden Messenger-Service als Forward sowie Reverse-Proxy bereitgestellt werden. [<=]

A_25368 - Invites beim createRoom

Der Messenger-Proxy MUSS sicherstellen, dass beim Anlegen eines Raumes das Attribut "invite" mit maximal einer MXID befüllt ist. [<=]

A_25538 - Too many invites

Ist das Attribute "invite" mit mehr als einem Element befüllt, dann MUSS der Messenger-Proxy an den TI-M Client das folgenden JSON-Objekt zurückgeben: 

A_25630 - Forward Proxy

Die Kommunikation des Matrix Homeservers in das Internet MUSS immer über den eigenen Messenger-Proxy (in der Funktion als Forward-Proxy) erfolgen.  [<=]

A_25539 - Userinfo für VZD-FHIR-Directory

Der Messenger-Proxy MUSS dem VZD-FHIR-Directory Zugriff auf den Endpunkt /_matrix/federation/v1/openid/userinfo der Matrix-Homeserver ermöglichen.  [<=]

A_25632 - Signatur der Föderationsliste

Der Messenger-Proxy MUSS zur Prüfung der Signatur der Föderationsliste das im Signatur-Header enthaltene Signaturzertifikat (öffentliche Schlüssel) und das X.509-Root-CA Zertifikat der TI verwenden. [<=]

A_25635 - OCSP-Responder

Die Gültigkeit des Signaturzertifikates MUSS mit Hilfe des [OCSP-Responder] validiert werden. [<=]

A_25634 - Zertifikatsaktualisierung

Der Messenger-Proxy MUSS wöchentlich prüfen, ob neue X.509-Root-CA-Versionen existieren und Cross-Zertifikate verfügbar sind. Ist dies der Fall, MUSS der Messenger-Proxy diese neuen Root-Versionen in seinen Truststore importieren. [<=]

A_25530 - Client-Server API

TI-M FD MÜSSEN sicherstellen, dass die Matrix-Homeserver die [Client-Server API] umsetzen. [<=]

A_25344 - Server-Server API

TI-M FD MÜSSEN sicherstellen, dass die Matrix-Homeserver die [Server-Server API] umsetzen. [<=]

A_25531 - Appendices TI-M FD

TI-M FD MÜSSEN sicherstellen, dass die Matrix-Homeserver [Matrix Appendices] umsetzen. [<=]

A_26191 - Verbot des Ausstellens von Login-Tokens

Der TI-M Fachdienst MUSS jedes Request zum Endpunkt /login/get_token¹ mit einer HTTP 400/404 Response beantworten, ohne ein Token auszustellen.
¹ [Client-Server API/#post_matrixclientv1loginget_token] [<=]

A_26243 - Verbot von Guest Accounts

Der TI-M Fachdienst MUSS das Registrieren von Gastzugängen unterbinden, indem er Requests zum Endpunkt /register¹ mit dem Queryparameter kind=guest mit einer HTTP 403 Response beantwortet ohne ein Access Token auszustellen.
¹ [Client-Server API/#post_matrixclientv3register] [<=]

A_25393 - Ausgabe von access token durch den TI-M FD

Der TI-M FD MUSS die Komponente Matrix-Homeserver so implementieren, dass bei erfolgreichem Aufruf der [Client-Server API] Endpoints /login und /register neue access token und refresh token ausgegeben werden. [<=]

A_25352 - Gültigkeitsdauer von access token des TI-M FD

Der TI-M FD MUSS die Komponente Matrix-Homeserver so implementieren, dass vom Matrix-Homeserver ausgestellte access token eine Gültigkeitsdauer von max. 24 Stunden haben. [<=]

A_25353 - Gültigkeitsdauer von refresh token des TI-M FD

Der TI-M FD MUSS die Komponente Matrix-Homeserver so implementieren, dass vom Matrix-Homeserver ausgestellte refresh token eine Gültigkeitsdauer von max. 6 Monaten haben. [<=]

A_25322 - Create Room

Der Matrix-Homeserver MUSS beim Aufruf der API zum Anlegen eines Raumes nur die Einladung maximal einer MXID zulassen.  [<=]

A_25318 - Löschfunktion für Matrix-Homeserver

Matrix-Homeserver MÜSSEN eine Funktion anbieten, durch die Events, Gesprächsinhalte und mit einzelnen Gesprächen assoziierte Daten (z. B. versandte Dateien) nach einem festgelegten Zeitraum seit letzter Aktivität in einem Raum gelöscht werden. [<=]

A_25319 - Zeitraum zur Auslösung der Löschfunktion für Matrix-Homeserver

Die Löschfunktion für Matrix-Homeserver MUSS auf sechs Monate voreingestellt und durch einen Akteur in der Rolle "Org-Admin" konfigurierbar sein. [<=]

A_26210 - Verpflichtende Unterstützung von Modulen durch TI-M FD

Der TI-M Fachdienst MUSS Client-Module aus 3.1.3.1 Umdefinition der Module, die den Anforderungs-Level MUSS, SOLL oder KANN tragen, verpflichtend unterstützen. [<=]

A_26224 - Abruf einzelner öffentlicher Schlüssel durch andere Fachdienste

Der TI-M Fachdienst MUSS die folgenden Endpunkte zum Abruf öffentlicher Schlüssel durch andere Fachdienste anbieten:

• GET /_matrix/key/v2/server/{keyId}
• GET /_matrix/key/v2/query/{serverName}/{keyId}

A_26226 - Verbot des Abrufes einzelner öffentlicher Schlüssel

Der TI-M Fachdienst DARF die Endpunkte /_matrix/key/v2/server/{keyId} und /_matrix/key/v2/query/{serverName}/{keyId} NICHT aufrufen. [<=]

A_26263 - Unauthenticated Media

Der TI-M Fachdienst DARF den Download von Medien über die nicht authentifizierten Endpunkte

• GET /_matrix/media/v3/download/{serverName}/{mediaId}
• GET /_matrix/media/v3/download/{serverName}/{mediaId}/{fileName}
• GET /_matrix/media/v3/thumbnail/{serverName}/{mediaId}

A_26344 - Verbot von URL-Previews

Der TI-M Fachdienst MUSS Requests zu folgenden Endpunkten mit einer HTTP 404 Response ablehnen ohne die übergebene URL aufzurufen:

• GET /_matrix/media/v3/preview_url
• GET /_matrix/client/v1/media/preview_url

A_26265 - TI-M FD Org-Admin Support

Der TI-M Fachdienst MUSS den Endpunkt /.well-known/matrix/support bereitstellen um dort Kontaktmöglichkeiten zum Org-Admin hinterlegen zu können. [<=]

A_26266 - TI-M Anbieter Org-Admin Support

Der TI-M Anbieter SOLL beim Endpunkt /.well-known/matrix/support Kontaktinformationen zum Org-Admin hinterlegen. [<=]

A_26289 - Authentisierung von Profilabfragen

Der TI-M Fachdienst MUSS nicht authentisierte Requests zu den folgenden Endpunkten mit einer HTTP 401 Response ablehnen:

• GET /_matrix/client/v3/profile/{userId}
• GET /_matrix/client/v3/profile/{userId}/avatar_url
• GET /_matrix/client/v3/profile/{userId}/displayname

A_26374 - Profilabfragen bei gemeinsamen Räumen

Der TI-M Fachdienst MUSS Profilabfragen über die folgenden Endpunkte erlauben, sofern der anfragende und der angefragte Nutzer gemeinsame Räume haben:

• GET /_matrix/client/v3/profile/{userId}
• GET /_matrix/client/v3/profile/{userId}/avatar_url
• GET /_matrix/client/v3/profile/{userId}/displayname

A_26330 - Authentisierung von Versionsabfragen

Der Matrix Homeserver MUSS ausgehende Requests zum Endpunkt /_matrix/federation/v1/version¹ gemäß [Server-Server API/#request-authentication] authentisieren.
¹ [Server-Server API/#get_matrixfederationv1version] [<=]

A_26331 - Ablehnung nicht authentisierter Versionsabfragen

Der TI-M Fachdienst MUSS nicht authentisierte Requests zum Endpunkt /_matrix/federation/v1/version¹ mit einer HTTP 401 Response ablehnen.
¹ [Server-Server API/#get_matrixfederationv1version] [<=]

A_25299 - Flächendeckende Verwendung von TLS

Sämtliche Kommunikation zwischen Komponenten des TI-M Dienstes MUSS TLS-verschlüsselt erfolgen, sofern die Kommunikation die Grenzen einer virtuellen/physischen Maschine überschreitet.
[<=]

A_25303 - Mindestens serverseitiges TLS

Im Rahmen der Kommunikation per TLS MUSS mindestens serverseitiges TLS verwendet werden.
[<=]

A_25301 - Authentifizierung von Clients

Server MÜSSEN Clients authentifizieren, bevor Ihnen - den Clients - Zugriff auf Ressourcen gewährt wird, die nicht frei zur Verfügung stehen.
[<=]

A_25302 - Art der Client-Authentifizierung

Clients SOLLEN sich gegenüber Servern per TLS-Client-Zertifikat oder einem Verfahren mit vergleichbarem Sicherheitsniveau authentisieren. [<=]

A_25311 - Minimale Qualität von Passwörtern

Der Anbieter des TI-M FD MUSS Vorgaben zur minimalen Qualität von Passwörtern entsprechend [BSI ORP.4] A.22 machen und die Einhaltung dieser Vorgaben an allen Stellen gewährleisten, an denen Passwörter im Rahmen der Konfiguration festzulegen sind.  [<=]

A_25312 - Instruktion über Einhaltung von Vorgaben zu Passwörtern

Der Anbieter MUSS die Organisation, welche den TI-Messenger Dienst von ihm bezieht, über die Notwendigkeit der Einhaltung der Vorgaben aus [BSI ORP.4] A8 instruieren. Diese beinhalten sicherheitsrelevante Anforderungen hinsichtlich der Nutzung und des Umgangs mit Passwörtern, richten sich jedoch an den operativen Betrieb durch die Leistungserbringerinstitution bzw. den Kostenträger, der vom Anbieter nicht kontrolliert werden kann. [<=]

A_25313 - Zwangsabmeldung und Sperrung von Akteuren

Wird ein Akteur in der Rolle "User" des TI-M Dienstes einer Organisation durch einen Akteur in der Rolle "Org-Admin" der Organisation gesperrt oder seine aktive Sitzung beendet - das heißt, er wird zwangsweise ausgeloggt -, so MUSS der TI-M FD die Weiterleitung von Nachrichten, die an diesen Akteur in der Rolle "User" gesendet werden oder von diesem gesendet werden, mit sofortiger Wirkung einstellen. [<=]

A_25314 - Einbringung kryptographischen Materials zur Authentisierung gegen das VZD-FHIR-Directory

TI-Messenger-Anbieter MÜSSEN sicherstellen, dass kryptographisches Material zur Authentisierung gegen das VZD-FHIR-Directory sicher eingebracht wird. Zum Nachweis der Umsetzung ist eine Prüfung des Prozesses zur Einbringung des kryptografischen Materials erforderlich. Die Prüfung umfasst die Beschreibung und Durchführung des Prozesses. Eine Auditierung der Umsetzung ist optional. [<=]

A_25315 - Explizites Verbot von Profiling für TI-Messenger-Hersteller

TI-Messenger-Hersteller DÜRFEN NICHT Daten zu Profilingzwecken sammeln. Dies betrifft insbesondere eine Überwachung, welche Akteure mit welchen anderen Akteuren kommunizieren. [<=]

A_25316 - Explizites Verbot von Profiling für TI-Messenger-Anbieter

TI-Messenger-Anbieter DÜRFEN NICHT Daten zu Profilingzwecken sammeln. Dies betrifft insbesondere eine Überwachung, welche Akteure mit welchen anderen Akteuren kommunizieren.  [<=]

A_25317 - Protokollierung zum Zwecke der Fehler- bzw. Störungsbehebung

Falls im TI-M FD eine Protokollierung zum Zwecke der Fehler- bzw. Störungsbehebung erfolgt, MUSS der Fachdienst unter Berücksichtigung des Art. 25 Abs. 2 DSGVO sicherstellen, dass in den Protokolldaten entsprechend dem Datenschutzgrundsatz nach Art. 5 DSGVO nur personenbezogene Daten in der Art und dem Umfang enthalten sind, wie sie zur Behebung erforderlich sind und dass die erzeugten Protokolldaten im Fachdienst nach der Behebung unverzüglich gelöscht werden. Sofern andere gesetzliche Grundlagen wie §331 SGB V nicht überwiegen, sind hierzu nur anonymisierte Daten zu protokollieren. [<=]

A_25327 - Sicherheitsrisiken von Software-Bibliotheken minimieren

TI-M FD-Hersteller MÜSSEN Maßnahmen umsetzen, um die Auswirkung von unentdeckten Schwachstellen in benutzten Software-Bibliotheken zu minimieren. [<=]

A_25328 - Wirksamkeit von Maßnahmen zur Minimierung von Sicherheitsrisiken

Die zur Minimierung der Auswirkungen von unentdeckten Schwachstellen in benutzten Software-Bibliotheken umgesetzten Maßnahmen MÜSSEN wenigstens die gleiche Wirksamkeit aufweisen, wie die Kapselung gemäß [OWASP Proactive Control#C2 Punkt 4]. [<=]

A_25333 - Abweichungen vom Matrix-Standard

TI-M FD-Hersteller MÜSSEN sämtliche nicht in der TI-Messenger-Spezifikation beschriebenen Abweichungen vom Matrix-Protokoll oder den MUST- oder SHOULD-Empfehlungen des Matrix-Protokolls dokumentieren und begründen. [<=]

A_25334 - Interoperabilität von Zusatzfunktionen für den TI-M FD

TI-M FD-Hersteller MÜSSEN sicherstellen, dass alle implementierten Funktionen, die über den gewöhnlichen Funktionsumfang einer TI-Messenger-Komponente hinausgehen, die Sicherheit des Produkts nicht gefährden und die Interoperabilität mit anderen TI-Messenger-Produkten gewährleisten. [<=]

A_25342 - Einsatz geschulter Administratoren

TI-Messenger-Anbieter MÜSSEN als Administratoren Personal einsetzen, welches für die damit verbundenen Aufgaben und Themen der Informationssicherheit geschult und sensibilisiert wurden. [<=]

A_25343 - Berechtigung von Administratoren

TI-Messenger-Anbieter MÜSSEN technisch sicherstellen, dass nur die berechtigten Administratoren administrativen Zugriff auf die zu verwaltenden Messenger-Services haben. [<=]

A_25556 - Test des TI-M Clients gegen die Referenzimplementierung

Der TI-M Client MUSS gegen die Referenzimplementierung erfolgreich getestet werden. Die Testergebnisse sind der gematik vorzulegen. [<=]

A_25623 - Test des TI-M FD gegen die Referenzimplementierung

Der Hersteller des TI-M FD MUSS den Fachdienst gegen die Referenzimplementierung erfolgreich testen. Die Testergebnisse sind der gematik vorzulegen. [<=]

A_25619 - TI-Messenger Instanzen

Der TI-Messenger-Anbieter MUSS eine Referenzinstanz und mindestens eine Testinstanz des TI-M FD und TI-M Clients bereitstellen und betreiben. [<=]

A_25620 - Nutzung der Referenz- und Testinstanzen

Der TI-Messenger-Anbieter MUSS die verschiedenen Benutzer der Referenzinstanz und der Testinstanz koordinieren (z. B. Verwaltung eines Test-/Nutzungsplans). [<=]

A_25621 - Weitere Testinstanzen

Bei Bedarf (Entwicklung verschiedener Versionen, hoher Auslastung durch andere Hersteller oder durch die gematik) MUSS der TI-Messenger-Anbieter auch mehrere Testinstanzen mit der gleichen oder mit verschiedene Versionen bereitstellen und betreiben. [<=]

A_25622 - Umsetzung des Testkonzepts

Die TI-Messenger Hersteller MÜSSEN sicherstellen, dass das Testkonzept [gematik Testkonzept] vollständig umgesetzt wird. [<=]

A_25250 - TI-Messenger Anbieter - Produktverantwortung (Basis)

Der TI-Messenger Anbieter MUSS mindestens einen:

• TI-Messenger Fachdienst

A_26219 - TI-M Anbieter Monitoring

Der TI-Messenger-Anbieter MUSS das Service Monitoring der gematik technisch-organisatorisch unterstützen. [<=]

A_25379 - TI-M Gültigkeitsprüfung der Organisation am VZD-FHIR-Directory

Der TI-M FD MUSS mindestens alle 24 Stunden, für alle bei ihm registrierten Organisationen mit einem Messenger-Service, prüfen, ob diese im VZD-FHIR-Directory als "active" (Organization.active) eingetragen sind. [<=]

A_25380 - TI-M Information bei ausgetragener Organisation am VZD-FHIR-Directory

Wenn die Organisation nicht mehr im VZD-FHIR-Directory "active" (Organization.active) ist, MUSS der TI-Messenger-Anbieter diese darüber informieren. [<=]

A_25381 - TI-M Sperrung der Organisation mit ungültigem SM-B bzw. ungültiger SMC-B

Wenn die Organisation länger als 30 Kalendertage nicht im VZD-FHIR-Directory "active" (Organization.active) ist, MUSS der TI-Messenger-Anbieter die Domäne dieses Messenger-Service aus der Föderation löschen (siehe FHIR-VZD: I_VZD_TIM_Provider_Services, DELETE /federation/{domain}). Dann DARF erst nach erneuter Authentifizierung per SM(C)-B der Dienst wieder genutzt werden, siehe AF_10103. [<=]

A_26095 - logische Trennung Messenger-Services

Werden durch einen TI-Messenger-Anbieter mehrere Domains in einem gemeinsamen Messenger-Service betrieben, so MUSS die logische Trennung der Matrix-Domains sichergestellt werden.

Hinweis: Die Anforderungen A_25381 & A_25382 erfordern die Zuordnung einer Organisation zu einer Domain, um einer Organisation die Teilnahme an der Föderation zu entziehen.
[<=]

A_25382 - TI-M kontrollierte Außerbetriebnahme

Wenn z. B. das Vertragsverhältnis zwischen Kunde und TI-Messenger-Anbieter ausläuft, so MUSS der TI-Messenger-Anbieter die dazugehörige Domäne dieses Messenger-Service aus der Föderation löschen (siehe FHIR-VZD: I_VZD_TIM_Provider_Services, DELETE /federation/{domain}) und den Messenger-Service abschalten, so dass dieser nicht mehr erreicht werden kann. [<=]

A_23658-01 - Produktnachweise im Rahmen der kontrollierten Inbetriebnahme

Das Produkt MUSS die Vorgaben zur Funktionalität, Sicherheit und Interoperabilität entsprechend des jeweiligen Produkttypsteckbriefs in der Produktivumgebung erfüllen. Die Nachweise dafür MÜSSEN entsprechend und im Rahmen des Konzepts zur kontrollierten Inbetriebnahme erbracht werden. [<=]

A_26247 - SRV Records

Verwendet ein TI-M Fachdienst Anbieter für die Auffindbarkeit seines Homeservers DNS-SRV-Einträge, so MUSS er neben einem Eintrag zum Servicenamen _matrix-fed auch einen Eintrag zum Servicenamen _matrix einpflegen. [<=]

A_25383 - TI-M Client Anbietersupport

Der TI-Messenger-Anbieter MUSS seine Nutzer bzw. die Akteure dabei unterstützen, einen sicheren und funktionalen Betrieb der TI-M Clients zu ermöglichen. [<=]

A_25548 - Information über Updates für den Client

Hersteller des TI-M Client MÜSSEN sicherstellen, dass Akteure über die Veröffentlichung von Updates für ihre TI-M Clients informiert werden, bspw. durch Mitteilung innerhalb und mittels des TI-M Clients. [<=]

A_25549 - Information über Notwendigkeit von Sicherheitsupdates

Hersteller des TI-M Clients MÜSSEN sicherstellen, dass Akteure geeignet über die Notwendigkeit der Installation sicherheitskritischer Updates informiert werden, um den TI-M Client weiterhin nutzen zu können. [<=]

A_25550 - Sperrung von Clients ohne Sicherheitsupdates

TI-M Client-Hersteller MÜSSEN sicherstellen, dass nach einer geeigneten Frist eine weitere Nutzung des TI-M Clients ohne vorheriges Sicherheitsupdate nicht möglich ist. Hierzu genügt eine client-seitige Sperre anstatt eines Nachweises gegenüber dem Matrix-Homeserver. [<=]

A_25551 - Fähigkeit zum Update im gesperrten Zustand

Ist ein TI-M Client wegen ausgebliebener Installation von Sicherheitsupdates nicht mehr für die Kommunikation nutzbar, MUSS die Möglichkeit der Installation von Updates weiterhin gegeben sein. [<=]

A_25552 - Information und Nachweis der Eignung

Der Hersteller des TI-M Clients MUSS die gematik bei Veröffentlichung einer neuen Produktversion informieren und eine Erklärung zur sicherheitstechnischen Eignung liefern. [<=]

A_25565 - Explizites Verbot von Profiling für TI-M Clients

TI-M Client-Hersteller und -Anbieter DÜRFEN NICHT Daten zu Profiling-Zwecken sammeln. Dies betrifft insbesondere eine Überwachung welche Akteure mit welchen anderen Akteuren kommunizieren. [<=]

A_25582 - Vertrauenswürdige Bezugsquellen für den TI-M Client

Der Hersteller eines TI-M Clients MUSS Akteure über die vertrauenswürdigen Quellen informieren, von denen Akteure den TI-M Client beziehen können und wie sie die Vertrauenswürdigkeit der Quelle erkennen können. [<=]

A_25583 - Möglichkeit der Authentizitätsprüfung

Der Hersteller MUSS sicherstellen, dass der Akteur bei Erstbezug eines TI-M Clients die Authentizität der vertrauenswürdigen Bezugsquelle verifizieren kann. [<=]

AF_10103-02 - Authentisieren einer Organisation am TI-M Dienst

Mit diesem Anwendungsfall authentisiert ein Akteur, in der Rolle "Org-Admin", seine Organisation bei einem TI-Messenger-Anbieter. Für die Authentisierung einer Organisation stellt der TI-M FD eine Schnittstelle an seinem Registrierungs-Dienst bereit. Diese wird über das Frontend des Registrierungs-Dienstes für die Authentisierung verwendet. Die Authentisierung der Organisation erfolgt individuell und nutzungsabhängig durch einen Akteur in der Rolle "Org-Admin". Im Rahmen der Authentifizierung MUSS der Besitz einer gültigen SM(C)-B nachgewiesen werden, da nur Organisationen des Gesundheitswesens berechtigt sind einen Messenger-Service zu erhalten. Als Nachweis ist eines der folgenden Verfahren zu verwenden:

• Verfahren 1: bei der Authentisierung am zentralen IDP-Dienst eine freigeschaltete SM(C)-B verwendet werden oder
• Verfahren 2: eine KIM-Nachricht an die Adresse der Organisation mit der freigeschalteten SM(C)-B gesendet werden.
  

Tabelle 4: Tabelle : AF - Authentisieren einer Organisation am TI-M Dienst

Abbildung 8: Laufzeitsicht - Authentisieren einer Organisation am TI-M Dienst 

A_25805 - AF_10103 - Organisation wurde erfolgreich verifiziert

Die im ID_TOKEN enthaltene ProfessionOID MUSS in der in [gemSpec_OID] in der Tabelle "Tab_PKI_403-x OID-Festlegung Institutionen im X.509-Zertifikat der SMC-B" gelisteten OIDs vorhanden sein. [<=]

A_25806 - AF_10103 - ID-Token wurde geprüft

Die Signatur des vom IDP-Dienst ausgestellten ID_TOKEN MUSS geprüft werden. [<=]

AF_10060-03 - Bereitstellung eines Messenger-Service für eine Organisation

Mit diesem Anwendungsfall wird einer zuvor am Registrierungs-Dienst authentifizierten Organisation ein Messenger-Service für diese Organisation durch einen Akteur in der Rolle "Org-Admin" bereitgestellt. Die Beantragung zur Bereitstellung eines Messenger-Service wird durch den Akteur in der Rolle "Org-Admin" am Frontend des Registrierungs-Dienstes vorgenommen. Dieser muss sich zuvor mit dem Admin-Account der Organisation am Registrierungs-Dienst anmelden. Für eine zeitnahe Adaption des TI-M Dienstes muss eine schnelle Bereitstellung von Messenger-Services gewährleistet sein. TI-Messenger-Anbieter sind verpflichtet, Prozesse zu etablieren, damit Messenger-Services für Organisationen schnell und ggf. automatisiert bereitgestellt werden können. Nach erfolgreicher Bereitstellung eines Messenger-Service wird dieser in die Föderation des TI-M Dienstes aufgenommen. Werden mehrere Messenger-Services für eine Organisation benötigt kann dieser Anwendungsfall mehrfach ausgeführt werden.

Tabelle 5: AF - Bereitstellung eines Messenger-Service für eine Organisation

Abbildung 9: Laufzeitsicht - Bereitstellung eines Messenger-Service für eine Organisation   

AF_10064-02 - Föderationszugehörigkeit eines Messenger-Service prüfen

Dieser Anwendungsfall prüft, ob ein Messenger-Service zugehörig zur TI-Messenger-Föderation ist, und gilt für alle Anwendungsfälle, welche die Matrix-Domain eines Messenger-Services überprüfen müssen. Für die Prüfung der Zugehörigkeit der Matrix-Domain zur TI-Messenger-Föderation verwendet der Messenger-Proxy eine Föderationsliste, die vom Registrierungs-Dienst seines TI-M FD bereitgestellt wird. Die Speicherdauer der Föderationsliste des Messenger-Proxies ist limitiert. Die Aktualisierung der Föderationsliste erfolgt wie in 5.1.7 Aktualisierung der Föderationsliste  beschrieben.

Tabelle 6: Föderationszugehörigkeit eines Messenger-Service prüfen

Abbildung 10: Laufzeitsicht - Föderationszugehörigkeit eines Messenger-Service prüfen 

A_26017 - AF_10064 - Matrix-Domain Teil der Föderationsliste & Aktualitätscheck

Es MUSS sichergestellt werden, dass der Registrierungs-Dienst die Föderationsliste auf Aktualität überprüft, bevor eine aktualisierte Liste durch den Messenger-Proxy abgerufen werden kann. Ebenfalls MUSS sichergestellt werden, dass der Messenger-Proxy tatsächlich überprüft, ob die Matrix-Domain des anderen Messenger-Service Teil der Föderationsliste ist.
[<=]

A_26018 - AF_10064 - Aktualität - Föderationsliste Messenger-Proxy

Es MUSS sichergestellt werden, dass die Föderationsliste vom Messenger-Proxy aktuell ist. Dafür MUSS der Messenger-Proxy in einem festen Intervall von einmal pro Stunde eine aktuelle Liste beim Registrierungs-Dienst anfordern.
[<=]

AF_10063-01 - Austausch von Events zwischen Akteuren innerhalb einer Organisation

Dieser Anwendungsfall ermöglicht es Akteuren, welche sich in einem gemeinsamen Raum innerhalb eines Messenger-Service befinden, Nachrichten auszutauschen und weitere durch die Matrix-Spezifikation festgelegte Aktionen (Events) auszuführen.

Tabelle 7: Austausch von Events zwischen Akteuren innerhalb einer Organisation

In der Laufzeitsicht sind die Interaktionen zwischen den Komponenten, die durch den Anwendungsfall genutzt werden, dargestellt. Hierbei handelt es sich um eine vereinfachte Laufzeitansicht, in der zum Beispiel die TLS-Terminierung am Messenger-Proxy auf Grund der Übersichtlichkeit nicht berücksichtigt wurde. Die in der Abbildung rot dargestellten Linien symbolisieren den Kommunikationsverlauf des auslösenden Matrix-Request. Für die vereinfachte Darstellung wird vorausgesetzt, dass die TI-M Clients der beteiligten Akteure online sind.

Abbildung 11: Laufzeitsicht - Austausch von Events zwischen Akteuren innerhalb einer Organisation

AF_10061-03 - Einladung von Akteuren außerhalb einer Organisation

In diesem Anwendungsfall wird ein Akteur außerhalb einer Organisation eingeladen. Für die Suche nach Akteuren außerhalb der Organisation kann das VZD-FHIR-Directory verwendet werden. Ist die MXID des gesuchten Akteurs dort nicht vorhanden, muss es die Möglichkeit geben, die Kontaktaufnahme auch auf anderen Wegen zu ermöglichen, mindestens mittels manueller Eingabe der MXID. Weitere Optionen wie z. B. QR-Code-Scans sind zulässig.

Tabelle 8: AF - Einladung von Akteuren außerhalb einer Organisation

Abbildung 12: Laufzeitsicht - Einladung von Akteuren außerhalb einer Organisation

AF_10062-03 - Austausch von Events zwischen Akteuren außerhalb einer Organisation

In diesem Anwendungsfall können Akteure, welche sich in einem gemeinsamen Raum befinden, Nachrichten austauschen und weitere in der Matrix-Spezifikation festgelegte Aktionen ausführen. Dieser Anwendungsfall setzt die erfolgreiche Annahme eines Invite-Events durch einen oder mehrere beteiligte Akteure voraus. Die Prüfung auf Domainzugehörigkeit findet bei jedem Event der Server-Server Kommunikation statt. In diesem Anwendungsfall sind die beteiligten Akteure in einem gemeinsamen Chatraum und auf unterschiedlichen Messenger-Services verteilt.

Tabelle 9: AF - Austausch von Events zwischen Akteuren außerhalb einer Organisation 

Abbildung 13: Laufzeitsicht - Austausch von Events zwischen Akteuren außerhalb einer Organisation

AF_10378 - Aktualisierung der Föderationsliste

Der Anwendungsfall beschreibt, wie ein TI-M FD ressourcenschonend die Föderationsliste vom VZD-FHIR-Directory aktualisiert und eine aktuelle Kopie der Liste am Registrierungs-Dienst und Messenger-Proxy vorhält.

Tabelle 10: AF - Aktualisierung der Föderationsliste

Abbildung 14: Laufzeitansicht - Aktualisierung der Föderationsliste

Abbildung 15: Provider authentifizieren und Föderationsliste abrufen

Abbildung 16: Signatur der Föderationsliste prüfen

A_25637-01 - Aktualisierung der Föderationsliste

Der Registrierungs-Dienst MUSS die Föderationsliste stündlich abfragen. Die Prüfung auf Aktualität der Föderationsliste des Registrierungs-Dienstes MUSS zusätzlich bei jeder Anfrage durch einen Messenger-Proxy zur Bereitstellung der Föderationsliste über eine Abfrage beim FHIR-Proxy des VZD-FHIR-Directory erfolgen, sofern die durch den Registrierungs-Dienst vorgehaltene Föderationsliste älter als eine Stunde ist. [<=]

A_26413 - Attribute des Registrierungsdienstes für Aktualisierungsfunktionalität der Föderationsliste

Der Registierungs-Dienst MUSS folgende Attribute und ihre Typen definieren und vorhalten:

Tabelle 11: Spezifische Attribute für das Handling der Föderationsliste am Registrierungs-Dienst

A_26415 - Abfrage der Föderationsliste am VZD-FHIR-Directory

Der Registrierungs-Dienst MUSS die aktuelle TI-M Föderationsliste anhand eines gültigen provider-accesstoken am VZD-FHIR-Directory abrufen und an der internen Schnittstelle I_internVerification bereitstellen. Für den Abruf MUSS die am FHIR-Proxy des VZD-FHIR-Directory bereitgestellte Operation getFederationList (GET /tim-provider-services/FederationList/federationList.jws) aufgerufen werden. [<=]

A_25638 - Caching der Föderationsliste nach Abfrage beim VZD-FHIR-Directory

Der Registrierungs-Dienst MUSS die Föderationsliste für Abfragen der Messenger-Proxies cachen, um nicht bei jeder Anfrage eines Proxies eine Anfrage an das VZD-FHIR-Directory zu stellen. [<=]

A_26417 - Prüfung des HealthState und Änderung der Vorhaltezeit der Föderationsliste

Der Registrierungs-Dienst MUSS seine eigene Vorhaltezeit der Föderationsliste auf einen festgelegten Wert von 72 Stunden (TTL_Föderationsliste) verlängern, sofern das VZD-FHIR-Directory nicht innerhalb einer definierten Antwortzeit erreichbar und weitere Aktualisierungsversuche erfolglos bleiben (HealthState_VZD und HealthStateCheck_VZD). [<=]

A_25636 - Maximale Alter der Föderationsliste

Der Messenger-Proxy MUSS die Kommunikation zu anderen Matrix-Homeservern einstellen, wenn Alter_Föderationsliste den Wert von TTL_Föderationsliste erreicht. [<=]

A_26418 - Prüfung des HealthState der Föderationsliste und Auslösen eines Incidents

Der Registrierungs-Dienst MUSS ein Incident-Event erzeugen, welches durch ein Drittsystem aufgefangen werden kann (z. B. ein ITSM-System) und es MUSS ein Incident beim VZD-FHIR-Directory-Anbieter eingestellt werden, sofern das VZD-FHIR-Directory nicht innerhalb einer definierten Antwortzeit erreichbar und weitere Aktualisierungsversuche erfolglos bleiben (HealthState_VZD und HealthStateCheck_VZD). [<=]

A_26419 - Weiternutzung einer vorgehaltenen Föderationsliste im Falle eines Incidents

Der Registrierungs-Dienst MUSS die vorgehaltene Föderationsliste weiterhin bereitstellen, bis zur Behebung eines Aktualisierungsstörfalls bzw. -incidents, aber höchstens bis zum Erreichen der festgelegten Vorhaltezeit (TTL_Föderationsliste). [<=]

A_26421 - Prüfung der Signatur der Föderationsliste durch Messenger-Proxy

Der Messenger-Proxy MUSS sicherstellen, dass seine lokale Kopie der Föderationsliste nur dann aktualisiert wird, wenn die Signatur der Föderationsliste anhand des Signaturzertifikats gültig ist. [<=]

AF_10235-01 - Einträge im VZD-FHIR-Directory suchen

Der Anwendungsfall beschreibt, wie ein Akteur im VZD-FHIR-Directory nach HealthcareService- und PractitionerRole-Ressourcen sucht. Dies setzt eine erfolgreiche Anmeldung des Akteurs an einem Messenger-Service voraus.

Tabelle 12: Einträge im VZD-FHIR-Directory suchen

Abbildung 17 : Laufzeitsicht - Einträge im VZD-FHIR-Directory suchen  

A_25532 - Prüfung Föderationszugehörigkeit

Bei jedem Invite-Event MUSS der Messenger-Proxy prüfen, ob die in der Anfrage enthaltenen Matrix-Domains zur TI-Föderation gehören (siehe Kapitel 5.1.3 Föderationszugehörigkeit prüfen).  [<=]

A_26328 - Prüfung eingehender Medienanfragen

Der Messenger-Proxy MUSS bei eingehender Kommunikation auf folgenden Endpunkten die Pfadkomponente {serverName}
auf Föderationszugehörigkeit prüfen:

• GET /_matrix/media/v3/download/{serverName}/{mediaId}
• GET /_matrix/media/v3/download/{serverName}/{mediaId}/{fileName}
• GET /_matrix/media/v3/thumbnail/{serverName}/{mediaId}

A_25537 - Aktualisierung Föderationsliste

Kann eine zu prüfende Domain nicht in der Föderationsliste gefunden werden, MUSS der Messenger-Proxy bei seinem Registrierungs-Dienst eine neue Version der Föderationsliste abrufen. [<=]

A_25534 - Fehlschlag Föderationsprüfung

Kann nach der Aktualisierung der Föderationsliste die Domain nicht in der Föderationsliste gefunden werden, dann MUSS der Messenger-Proxy die Anfrage mit dem folgenden JSON-Objekt ablehnen:

A_25533 - Server Föderationszugehörigkeit

Bei jedem Event MUSS der Messenger-Proxy die Föderationszugehörigkeit der im Event enthaltenen Matrix-Domains prüfen (siehe Kapitel 5.1.3 Föderationszugehörigkeit prüfen).  [<=]

A_25540-01 - Prüfung eingehender authentisierter Kommunikation

Ist auf einem eingehenden Request, im Authorization-Header das Attribut origin¹ gesetzt, so MUSS der Messenger-Proxy den enthaltenen Servernamen auf Föderationszugehörigkeit prüfen.
¹ [Server-Server API/#request-authentication] [<=]

A_25541-01 - Prüfung ausgehender authentisierter Kommunikation

Ist auf einem ausgehenden Request, im Authorization-Header das Attribut destination¹ gesetzt, so MUSS der Messenger-Proxy den enthaltenen Servernamen auf Föderationszugehörigkeit prüfen.
¹ [Server-Server API/#request-authentication] [<=]

A_26329 - Prüfung ausgehender .well-known Anfragen

Der Messenger-Proxy MUSS bei ausgehender Kommunikation zum Endpunkt /.well-known/matrix/server den im Host-Header enthaltenen Servernamen auf Föderationszugehörigkeit prüfen. [<=]

A_26341 - Prüfung ausgehender Medienanfragen

Der Messenger-Proxy MUSS bei ausgehender Kommunikation auf folgenden Endpunkten die Pfadkomponente {serverName} auf Föderationszugehörigkeit prüfen:

• GET /_matrix/media/v3/download/{serverName}/{mediaId}
• GET /_matrix/media/v3/download/{serverName}/{mediaId}/{fileName}
• GET /_matrix/media/v3/thumbnail/{serverName}/{mediaId}

A_25045-01 - Funktionsumfang der Berechtigungskonfiguration

Der TI-M Client MUSS für die Konfiguration der Berechtigungen folgende Varianten unterstützen:

1. Basiseinstellung ist "allow all" und der Akteur pflegt eine BlockedUser-Liste.
2. Basiseinstellung ist "block all" und der Akteur pflegt eine AllowedUser-Liste.

A_26016 - Basiseinstellung vorgeben

Der TI-M Client MUSS ermöglichen, dass ein TI-Messenger-Anbieter die Basiseinstellung der Berechtigungskonfiguration vordefinieren kann.  [<=]

A_25043 - Berechtigungskonfiguration in Accountdaten speichern

Der TI-M Client MUSS die Berechtigungskonfiguration aus den Accountdaten des Matrix-Homeservers [Client-Server API/#client-config] beziehen und Änderungen an der Berechtigungskonfiguration in den Accountdaten des Matrix-Homeservers speichern. [<=]

A_26021 - Durchsetzung der Berechtigungskonfiguration - Fachdienst

Der TI-M FD KANN die hinterlegte Berechtigungskonfiguration durchsetzen. [<=]

A_25046 - Durchsetzung der Berechtigungskonfiguration - Client

Der TI-M Client MUSS die hinterlegte Berechtigungskonfiguration durchsetzen, wenn der verwendete Fachdienst die Durchsetzung nicht anbietet. [<=]

A_22965-01 - Push-Benachrichtigungen Messenger-Anbieter

TI-Messenger-Anbieter MÜSSEN sicherstellen, dass Push-Benachrichtigungen erst nach expliziter Zustimmung der Nutzer erfolgen (Opt-In) dürfen. [<=]

A_25033 - Bereitstellung Push Gateway

Für TI-M Clients für mobile Szenarien MUSS ein Push-Gateway bereitgestellt werden, über welches die App mit Push-Benachrichtigungen beliefert wird. [<=]

A_25286 - Push-Gateway API

Das Push-Gateway MUSS für Homeserver eine API gemäß [Push Gateway API] bereitstellen. [<=]

A_25034 - TI-M Fachdienst - Push Notifications Datenschutz

Der TI-M Fachdienst MUSS das Push-Format "event_id_only" beim Anlegen eines Pushers über die [Client-Server API/#push-notifications] durchsetzen. [<=]

A_22808-01 - Push-Benachrichtigungen Timing

Push-Nachrichten MÜSSEN vor dem Versenden um einen Zufallswert von 0-10 Sekunden verzögert werden, um timingbasierte Profilbildung zu erschweren. [<=]

A_26200 - Unterstützte Raumversionen am Client

Der TI-M Client MUSS die Raumversionen 9, 10 und 11 gemäß [Room Versions] unterstützen. [<=]

A_26201 - Unterstützte Raumversionen am Fachdienst

Der TI-M Fachdienst MUSS die Raumversionen 9, 10 und 11 gemäß [Room Versions] unterstützen. [<=]

A_26202 - Erlaubte Raumversionen beim Erstellen von Räumen

Der TI-M Fachdienst MUSS die Verwendung anderer Raumversionen als 9 und 10 beim Erstellen von Räumen verhindern, z. B. indem er entsprechende Requests an den Endpunkt /createRoom mit einer HTTP 400 Response ablehnt. [<=]

A_26248 - Default-Raumversion beim Erstellen von Räumen

Der TI-M Fachdienst MUSS beim Erstellen von Räumen standardmäßig Raumversion 10 verwenden, sofern vom TI-M Client keine andere Version angefragt wurde. [<=]

A_26203 - Erlaubte Raumversionen beim Upgrade von Räumen

Der TI-M Fachdienst MUSS Upgrades auf andere Raumversionen als 9 und 10 verhindern, z. B. indem er entsprechende Requests an den Endpunkt /rooms/{roomId}/upgrade mit einer HTTP 400 Response ablehnt. [<=]

A_26338 - Erzeugung und Verwendung der Custom State Events für Raumnamen und -thema

In Räumen mit Custom Room Types der Form de.gematik.tim.roomtype.* MUSS der TI-M Client die Custom State Events de.gematik.tim.room.name und de.gematik.tim.room.topic anstelle der Standard State Events m.room.name und m.room.topic verwenden. Der TI-M Client MUSS dabei sicherstellen, dass das Schema dieser Custom State Events bis auf den Event Type identisch zu den Standard State Events ist und, dass die Felder name und topic im Event Content der Standard State Events leer sind (0-Längen-Zeichenkette). [<=]

A_25820-01 - Auswertung der Custom State Events für Raumnamen und -thema

An allen Stellen, an denen gemäß [Matrix Specification] die Standard State Events m.room.name und m.room.topic ausgewertet werden, SOLL der Matrix-Homeserver stattdessen die Inhalte der Custom State Events de.gematik.tim.room.name und de.gematik.tim.room.topic verwenden. Dies betrifft insbesondere die Zusammenstellung des Stripped State¹ von Räumen, die Replikation von State Events im Rahmen von Raum-Upgrades und die serverseitige Suche in Events.
¹ [Client-Server API/#stripped-state] [<=]

A_25755 - Verwendung eines spezifischen Chatroom-Typen für fallbezogene Kommunikation

Der TI-M Client MUSS den Custom Room Type "de.gematik.tim.roomtype.casereference.v1" für die fallbezogene Kommunikation mit Hilfe eines parametrisierten Aufrufs des /createRoom Endpunktes erzeugen und verwenden. [<=]

A_25756 - Pflichtparameter bei der Chatroom-Erzeugung für fallbezogene Kommunikation

Der Custom Room Type "de.gematik.tim.roomtype.casereference.v1" MUSS über den Aufruf des /createRoom Endpunkts erzeugt werden. Diese Pflichtparameter sind dabei zu verwenden (dargestellt als sortierte hierarchische Liste):

• creation_content
• type: de.gematik.tim.roomtype.casereference.v1
• initial_state (State Event Liste)
• de.gematik.tim.room.casereference.v1 (Custom State Event)
• Event type: de.gematik.tim.room.casereference.v1
  Event state_key: <vom Sender festgelegt>
  Event content: <wird in [simplifier] definiert>
• de.gematik.tim.room.name (Custom State Event)
• <Beschreibung siehe Abschnitt "Basis-Anwendungsfall">
  
• de.gematik.tim.room.topic (Custom State Event)
• <Beschreibung siehe Abschnitt "Basis-Anwendungsfall">
• name
• <leer> (0-Längen-Zeichenkette)
• topic
• <leer> (0-Längen-Zeichenkette)

A_25757 - Verwendung von spezifischen FHIR-Ressourcen im Event Content für fallbezogene Kommunikation

Für die Abbildung der fallbezogenen Kommunikation MÜSSEN spezifische FHIR-Ressourcen im Event Content als JSON-Daten eingetragen werden. Weiterhin MÜSSEN diese FHIR-Ressourcen als FHIR-Bundle zusammengefasst werden. Diese FHIR-Ressourcen MÜSSEN den Profilvorgaben aus dem Simplifier-Projekt [simplifier] entsprechen. [<=]

A_25808 - Erzeugung von spezifischen State Events für fallbezogene Kommunikation

Der TI-M Client MUSS ein Custom State Event mit dem Event Type "de.gematik.tim.room.casereference.v1" in einem Chatroom-Typ des Custom Room Types "de.gematik.tim.roomtype.casereference.v1" erzeugen können. [<=]

A_25811 - Entgegennehmen von spezifischen State Events und Room Types für die fallbezogene Kommunikation

Der Matrix-Homeserver MUSS die folgenden Custom Room Types sowie die folgenden Event Types der Custom State Events entgegennehmen können, ohne diese auszuwerten, abzuweisen oder auf diese mit einer Fehlermeldung zu reagieren:

• Custom Room Type: de.gematik.tim.roomtype.casereference.v1
• Custom State Event: de.gematik.tim.room.casereference.v1

A_25426 - Verwendung des Chatroom-Typen für föderierte und intersektorale Kommunikation

Der TI-M Client MUSS den Custom Room Type "de.gematik.tim.roomtype.default.v1" für die föderierte und intersektorale Kommunikation mit Hilfe eines parametrisierten Aufrufs des /createRoom Endpunktes erzeugen und verwenden. [<=]

A_25814-01 - Verwendung des Raumtypen für föderierte und intersektorale Kommunikation als Standard

Der TI-M Client MUSS standardmäßig den Raumtyp de.gematik.tim.roomtype.default.v1 verwenden, sofern nicht explizit ein anderer, von der gematik zugelassener Custom Room Type durch den raumerzeugenden Nutzer ausgewählt wird. [<=]

A_25813 - Pflichtparameter bei der Chatroom-Erzeugung für föderierte und intersektorale Kommunikation

Der Custom Room Type "de.gematik.tim.roomtype.default.v1" wird über den Aufruf des /createRoom Endpunkts erzeugt. Diese Pflichtparameter sind dabei zu verwenden (dargestellt als sortierte hierarchische Liste):

• creation_content
• type: de.gematik.tim.roomtype.default.v1
• initial_state (State Event Liste)
• de.gematik.tim.room.default.v1 (Custom State Event)
• Event type: de.gematik.tim.room.default.v1
  Event state_key: <vom Sender festgelegt>
  Event content: <wird in [simplifier] definiert>
• de.gematik.tim.room.name (Custom State Event)
• <Beschreibung siehe Abschnitt "Basis-Anwendungsfall">
  
• de.gematik.tim.room.topic (Custom State Event)
• <Beschreibung siehe Abschnitt "Basis-Anwendungsfall">
• name
• <leer> (0-Längen-Zeichenkette)
• topic
• <leer> (0-Längen-Zeichenkette)

A_25816 - Erzeugung von spezifischen State Events für föderierte und intersektorale Kommunikation

Der TI-M Client MUSS ein Custom State Event mit dem Event Type "de.gematik.tim.room.default.v1" in einem Chatroom-Typ des Custom Room Types "de.gematik.tim.roomtype.default.v1" erzeugen können. [<=]

A_25818 - Entgegennehmen von spezifischen State Events und Room Types für föderierte und intersektorale Kommunikation

Der Matrix-Homeserver MUSS die folgenden Custom Room Types sowie die folgenden Event Types der Custom State Events entgegennehmen können, ohne diese auszuwerten, abzuweisen oder auf diese mit einer Fehlermeldung zu reagieren:

• Custom Room Type: de.gematik.tim.roomtype.default.v1
• Custom State Event: de.gematik.tim.room.default.v1