Elektronische Gesundheitskarte und Telematikinfrastruktur
Spezifikation
TI-Messenger-Fachdienst
| Version | 1.0.0 |
| Revision | 548770 |
| Stand | 01.10.2021 |
| Status | freigegeben |
| Klassifizierung | öffentlich |
| Referenzierung | gemSpec_TI-Messenger-FD |
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
| Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
|---|---|---|---|---|
| 1.0.0 | 01.10.2021 | Erstversion des Dokumentes | gematik | |
Beim vorliegenden Dokument handelt es sich um die Festlegungen zur ersten Ausbaustufe des TI-Messengers. Diese Ausbaustufe ist definiert durch die Ad-hoc-Kommunikation zwischen Organisationen des Gesundheitswesens. Dabei wird insbesondere die Ad-hoc-Kommunikation zwischen Leistungserbringern bzw. zwischen Leistungserbringerinstitutionen betrachtet. Festlegungen zur Nutzergruppe der Versicherten und Anforderungen an Kassenorganisationen werden in der zweiten Ausbaustufe des TI-Messengers Berücksichtigung finden und daher im vorliegenden Dokument nicht weiter betrachtet.
Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps TI-Messenger-Fachdienst. Der Fachdienst ermöglicht die sichere Ad-hoc-Kommunikation zwischen Teilnehmern. Aus den Kommunikationsbeziehungen mit dem TI-Messenger-Client und dem VZD-FHIR-Directory resultieren vom TI-Messenger-Fachdienst anzubietende Schnittstellen, die in diesem Dokument normativ beschrieben werden. Vom TI-Messenger-Fachdienst genutzte Schnittstellen liegen zumeist in anderen Verantwortungsbereichen (z. B. IDP-Dienst). Diese werden in der entsprechenden Produkttypspezifikation definiert.
Das Dokument richtet sich zwecks der Realisierung an Hersteller des Produkttypen Fachdienst TI-Messenger sowie an Anbieter, welche diesen Produkttypen betreiben [gemKPT_Betr]. Alle Hersteller und Anbieter von TI-Anwendungen, die Schnittstellen der Komponente nutzen, oder Daten mit dem Produkttypen Fachdienst TI-Messenger austauschen oder solche Daten verarbeiten, müssen dieses Dokument ebenso berücksichtigen.
Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Anbietertypsteckbrief, u.a.) oder Webplattformen (z. B. gitHub, u.a.) festgelegt und bekanntgegeben.
Schutzrechts-/Patentrechtshinweis
Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.
Spezifiziert werden in dem Dokument die von dem Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang, Kapitel ).
Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps TI-Messenger verzeichnet.
Die Spezifikation ist im Stil einer RFC-Spezifikation verfasst. Dies bedeutet:
Anwendungsfälle und Akzeptanzkriterien als Ausdruck normativer Festlegungen werden als Grundlage für Erlangung der Zulassung durch Tests geprüft und nachgewiesen. Sie besitzen eine eindeutige, permanente ID, welche als Referenz verwendet werden SOLL. Die Tests werden gegen eine von der gematik gestellte Referenz-Implementierung durchgeführt.
Anwendungsfälle und Akzeptanzkriterien werden im Dokument wie folgt dargestellt:
<ID> - <Titel des Anwendungsfalles / Akzeptanzkriteriums>
Text / Beschreibung
[<=]
Die einzelnen Elemente beschreiben:
Dabei umfasst der Anwendungsfall bzw. das Akzeptanzkriterium sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.
Der für die Erlangung einer Zulassung notwendige Nachweis der Erfüllung des Anwendungsfalls wird in den jeweiligen Steckbriefen festgelegt, in denen jeweils der Anwendungsfall gelistet ist. Akzeptanzkriterien werden in der Regel nicht im Steckbrief gelistet.
Hinweis auf offene Punkte
| Offener Punkt: Das Kapitel wird in einer späteren Version des Dokumentes ergänzt. |
Der TI-Messenger-Fachdienst ermöglicht eine sichere Kommunikation verschiedener Teilnehmer im deutschen Gesundheitswesen. Der TI-Messenger-Fachdienst basiert auf dem offenen und dezentralen Kommunikationsprotokoll Matrix. Dabei stellt der Matrix Standard RESTful-APIs für die sichere Übertragung von JSON-Objekten zwischen Matrix-Clients und weiteren Diensten bereit. Die sichere Kommunikation zwischen den einzelnen Akteuren findet in verschlüsselter Form in Räumen auf den beteiligten Matrix-Homeservern statt.
Der TI-Messenger-Fachdienst besteht aus dezentralen und zentralen Teilkomponenten, die ein Anbieter bereitstellen MUSS. Bei den dezentralen Teilkomponenten handelt es sich um die Messenger-Services. Die Messenger-Services beinhalten jeweils Matrix-Homeserver und Komponenten, welche dafür sorgen, dass eine Föderation der Matrix-Homeserver nur zwischen verifizierten Domains stattfindet. Diese werden in der Spezifikation als Messenger-Proxy und PASSporT-Service bezeichnet. Messenger-Services werden für einzelne Organisationen (z. B. Leistungserbringerinstitutionen, Verbände) bereitgestellt und erlauben die Nutzung durch alle Nutzer einer Organisation. Weiterhin KÖNNEN Messenger-Services durch Organisationen bereitgestellt werden, die nur für Leistungserbringer nutzbar sind. Diese unterscheiden sich technisch nicht von anderen Messenger-Services. Einzig die zugeordnete Organisation bietet ein für Leistungserbringer Authentifizierungsverfahren an.
Die Kommunikation zwischen einem TI-Messenger-Client und einem TI-Messenger-Fachdienst erfolgt über die Messenger-Proxies der Messenger-Services. Hier findet zunächst die TLS-Terminierung der Verbindungen von den TI-Messenger-Clients statt. Der Messenger-Proxy kontrolliert die Föderation durch Abfragen am Registrierungs-Dienst. Hierbei wird geprüft, ob die beteiligten Matrix-Homeserver registrierte Mitglieder der Föderation sind und ein Teilnehmer berechtigt ist, Requests auf dem Homeserver auszulösen.
Neben den dezentralen Messenger-Services besteht der TI-Messenger-Fachdienst aus einem zentralen Registrierungs-Dienst sowie einem zentralen Push-Gateway. Über den Registrierungs-Dienst bekommt der Anbieter die Möglichkeit die Domainnamen der von ihm bereitgestellten Messenger-Services in das zentrale VZD-FHIR-Directory einzutragen, Messenger-Services automatisiert Organisationen zur Verfügung zu stellen und Domainabfragen vorzunehmen. Das Push-Gateway dient zur Übertragung von Benachrichtigungen (Notifications) an die jeweiligen TI-Messenger-Clients um den Eingang einer neuen Nachricht zu signalisieren. Für die Authentisierung von Nutzern des TI-Messenger kommen unterschiedliche Verfahren zur Anwendung. Beispielhaft soll auf die Möglichkeit der Verwendung eines IDP-Dienstes verwiesen werden.
Die folgende Abbildung zeigt einen Systemüberblick aller am TI-Messenger beteiligten Teilkomponenten in vereinfachter Form.
Abbildung 1: Systemüberblick (Vereinfachte Darstellung)
Der folgende Abschnitt setzt den TI-Messenger-Fachdienst in den Systemkontext des TI-Messenger-Dienstes.
Für den Betrieb des TI-Messenger-Fachdienstes werden weitere Systeme benötigt. Dazu gehört der Smartcard-IDP-Dienst der gematik und das VZD-FHIR-Directory. Die Abbildung Systemüberblick aus Kapitel 2 zeigt deren Beziehung zum TI-Messenger-Fachdienst.
Der Smartcard-IDP-Dienst stellt allen berechtigten Teilnehmern ID_TOKEN (AuthN) sowie ACCESS_TOKEN (AuthZ), gemäß des OpenID Foundation [OpenID] spezifizierten Protokolls, zur Verfügung. Mit den ausgestellten Token erfolgt die notwendige Authentisierung der TI-Messenger-Nutzer bei der initialen Registrierung eines Messenger-Service für eine Organisation, oder für schreibenden Zugriff auf das VZD-FHIR-Directory mittels TI-Messenger-Client. Dazu ist es notwendig das der TI-Messenger-Client und das Frontend des Registrierungs-Dienstes sich bei dem Smartcard IDP-Dienst registriert. Damit ist sichergestellt das Änderungen an den VZD-FHIR-Directory Einträgen durch den TI-Messenger-Client möglich sind.
Das zentrale VZD-FHIR-Directory bildet ein Verzeichnis aller TI-Messenger-Fachdienste, Organisationen und Leistungserbringer und bietet die Möglichkeit der Suche von Teilnehmern anhand konfigurierter Merkmale. Der TI-Messenger-Fachdienst trägt bei erfolgreicher Aufnahme in die Föderation im VZD-FHIR-Directory (in die Organisationsressource) seine Matrix-Domain ein. Das VZD-FHIR-Directory vertraut den Matrix-Homerservern der jeweiligen Messenger-Services, wenn die Domain des Messenger-Service erfolgreich in das VZD-FHIR-Directory eingetragen wurde.
Durch TI-Messenger-Anbieter werden Messenger-Services jeweils für eine Organisation des Gesundheitswesens (z. B. Arztpraxis, Krankenhaus, Apotheke, Verband, etc.) bereitgestellt. Die Bereitstellung erfolgt durch den Registrierungs-Dienst eines TI-Messenger-Anbieters dezentral und kann on-premise oder innerhalb von Rechenzentren stattfinden. Jeder Messenger-Service MUSS einer Organisation zugeordnet sein. Die Messenger-Services unterscheiden sich nur in den jeweils verwendeten Authentifizierungsverfahren. Diese werden durch die jeweilige Organisation festgelegt und bereitgestellt. Die jeweilige Organisation MUSS die Kontrolle über die Benutzerverwaltung haben, um zu jedem Zeitpunkt Nutzer aus dem TI-Messenger ausschließen zu können. Dabei MÜSSEN Nutzer vom Messenger-Service gelöscht/gesperrt werden, wenn der Nutzer innerhalb der Nutzerverwaltung gelöscht/gesperrt wurde.
Authentifizierungsverfahren
Messenger-Services können je nach Art der Organisation verschiedene Authentifizierungsverfahren anbieten. Sind bereits Systeme wie Active-Directory oder LDAP innerhalb einer Organisation verfügbar, können diese entsprechend genutzt werden, indem der Matrix-Homeserver bei diesen registriert wird. Sind keine Authentifizierungsverfahren vorhanden (z. B. innerhalb einer Arztpraxis) KÖNNEN TI-Messenger-Anbieter entsprechende Authentifizierungsverfahren zur Verfügung stellen. Diese erlauben einen Login für Nutzer (z. B. Benutzername/Passwort und einen zweiten Faktor) und können auch von weiteren Systemen nachgenutzt werden. Die nachfolgende Abbildung verdeutlicht das Authentifizieren von Nutzern an einen Messenger-Service.
Abbildung 2: Beispiel - Authentifizierung von Nutzern einer Organisation
ML-123614 - Verbot von Organisationsaccounts für Versicherte
Der Anbieter MUSS sicherstellen, dass organisationsbasierte TI-Messenger-Accounts nicht an Versicherte vergeben werden. Er MUSS sicherstellen, dass nur Accounts an Personen vergeben werden, mit denen ein Beschäftigungsverhältnis besteht. Hierzu ist eine organisatorische Lösung ausreichend.
[<=]
ML-123618 - PUSH-Benachrichtigungen
TI-Messenger-Anbieter MÜSSEN dafür sorgen, dass diese Gateways externe PUSH-Dienste datenschutzkonform nutzen. Hierzu wurden folgende Kriterien definiert, die in jedem Fall beachtet werden MÜSSEN:
Für Details der Verschlüsselung und enthaltene personenbezogene Daten siehe [MSC 3013].
ML-123615 - Flächendeckende Verwendung von TLS
Betreiber und Hersteller MÜSSEN sicherstellen, dass sämtliche Verbindungen zwischen Komponenten des TI-Messengers mittels TLS kommunizieren, sofern diese Kommunikation die Grenzen einer virtuellen/physischen Maschine überschreitet. Hierzu MUSS mindestens serverseitig authentizitätsgeschütztes TLS verwendet werden. Sofern kein beidseitiges TLS verwendet wird, MUSS die Authentizität der Clientseite mit gleichwertiger Sicherheit sichergestellt werden.Es gelten die Festlegungen aus [gemSpec_Krypt].
[<=]
ML-123616 - Abweichungen vom Matrix-Standard
Hersteller von TI-Messenger-Komponenten 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.
[<=]
ML-123617 - Löschfristen für Homeserver
Betreiber MÜSSEN sicherstellen, dass Events, Gesprächsinhalten und mit einzelnen Gesprächen assoziierte Daten (z.B. versandte Dateien) maximal für 6 Monate auf Homeservern verbleiben und danach gelöscht werden.
Hersteller MÜSSEN eine Funktion für Homeserver anbieten, über die eine Löschfrist für diese Daten konfigurierbar ist.
[<=]
ML-123621 - Interoperabilität von Zusatzfunktionen für den TI-Messenger-Fachdienst
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 erhalten. Ebenso MÜSSEN Hersteller sicherstellen, dass TI-Messenger-Fachdienstbestandteile resilient auf unerwartete Eingaben reagieren.
[<=]
ML-123619 - Protokollierung zum Zwecke der Fehler- bzw. Störungsbehebung
Falls im TI-Messenger-Fachdienst 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.
[<=]
ML-123620 - Explizites Verbot von Profiling für TI-Messenger-Anbieter
Anbieter von TI-Messenger-Komponenten DÜRFEN NICHT Daten zu Profilingzwecken sammeln. Dies betrifft insbesondere eine Überwachung welche Akteure mit welchen anderen Akteuren kommunizieren.
Die gematik kann nach § 331 Abs. 2 SGB V Daten festlegen, die Anbieter von Komponenten und Dienste der gematik offenzulegen bzw. zu übermitteln haben, sofern diese erforderlich sind, um den gesetzlichen Auftrag der gematik zur Überwachung des Betriebs zur Gewährleistung der Sicherheit, Verfügbarkeit und Nutzbarkeit der Telematikinfrastruktur zu erfüllen. Nur die hierfür erforderlichen personenbezogenen Daten dürfen von den Anbietern und Herstellern als Ausnahme vom Profilingverbot erhoben und ausschließlich für den genannten Zweck verwendet werden.
[<=]
ML-123622 - Behandlung von kryptographischem Material für OAuth
Betreiber von TI-Messenger-Messenger-Fachdiensten MÜSSEN sicherstellen, dass kryptographisches Material für OAuth, wie z.B. Client-ID und Client-Secret für Authentisierung mittels Credential-Flow sicher eingebracht werden. Dieses Material MUSS in Hardware Security Modules sicher gespeichert werden. [<=]
Zum Nachweis der Umsetzung ist lediglich eine Prüfung der Prozesse zur Einbringung erforderlich. Eine Auditierung der Umsetzung ist optional.
ML-123628 - Device Verification, Cross-Signing und SSSS für TI-Messenger-Fachdienste
Hersteller MÜSSEN sicherstellen, dass die Funktionen Cross-Signing und Secure Secret Storage and Sharing (SSSS) zur Device Verification unterstützt werden. Es MUSS die Spezifikation hinsichtlich Ende-zu-Ende Verschlüsselung vollständig befolgt werden.
[<=]
ML-123638 - Explizites Verbot von Profiling für TI-Messenger-Fachdienste
Betreiber von TI-Messenger-Komponenten DÜRFEN NICHT Daten zu Profilingzwecken sammeln. Dies betrifft insbesondere eine Überwachung welche Akteure mit welchen anderen Akteuren kommunizieren.
Die gematik kann nach § 331 Abs. 2 SGB V Daten festlegen, die Anbieter von Komponenten und Dienste der gematik offenzulegen bzw. zu übermitteln haben, sofern diese erforderlich sind, um den gesetzlichen Auftrag der gematik zur Überwachung des Betriebs zur Gewährleistung der Sicherheit, Verfügbarkeit und Nutzbarkeit der Telematikinfrastruktur zu erfüllen. Nur die hierfür erforderlichen personenbezogenen Daten dürfen von den Anbietern und Herstellern als Ausnahme vom Profilingverbot erhoben und ausschließlich für den genannten Zweck verwendet werden.
[<=]
ML-123637 - Sicherheitsrisiken von Software-Bibliotheken minimieren
Hersteller von TI-Messenger-Fachdiensten MÜSSEN Maßnahmen umsetzen, um die Auswirkung von unentdeckten Schwachstellen in benutzten Software-Bibliotheken zu minimieren.
Hinweis: Beispielmaßnahmen sind in [OWASP Proactive Control#C2] zu finden. Das gewählte Verfahren MUSS die gleiche Wirksamkeit aufweisen, wie die Kapselung gemäß [OWASP Proactive Control#C2 Punkt 4].
[<=]
ML-123635 - CC-Evaluierung als Ersatz für Gutachten
Falls der Hersteller entscheidet, eine CC-Zertifizierung statt eines Produktgutachtens durchzuführen, MUSS der Hersteller bei der Einreichung eines CC-Zertifizierungsantrags sein Security-Target-Dokument der gematik zur Verfügung stellen. In diesem MÜSSEN mindestens beschrieben sein:
ML-123634 - Sichere Produktentwicklung und Nachweise
Der Hersteller MUSS innerhalb des Produktlebenszyklus (Entwicklung, Betrieb, Außerbetriebnahme) seines Produktes Sicherheitsaktivitäten integrieren und anwenden, d. h. in einschlägigen Fachkreisen anerkannte, erprobte und bewährte Regeln anwenden.
Der Hersteller MUSS die Sicherheits- und Datenschutzmaßnahmen für sein Produkt in einem Sicherheits- und Datenschutzkonzept dokumentieren und auf Verlangen der gematik zur Verfügung stellen.
Der Hersteller MUSS einen Testplan für Sicherheitstests erstellen und auf Verlangen der gematik zur Verfügung stellen. Dieser MUSS umgesetzt werden und der gematik bei jeder Veröffentlichung einer Produktversion als neuer Bericht vorgelegt werden.
Der Hersteller des TI-Messenger-Clients für Nutzer MUSS während der Entwicklung des Produktes implementierungsspezifische Sicherheitsanforderungen dokumentieren und umsetzen.
Der Hersteller MUSS ein sicherheitsrelevanten Softwarearchitektur-Review durchführen und identifizierte Architekturschwachstellen beheben. Dieses Review MUSS nach jeder Architekturänderung mit Sicherheitsrelevanz wiederholt werden.
Der Hersteller MUSS eine Bedrohungsanalyse durchführen und Maßnahmen gegen die identifizierten Bedrohungen implementieren.
Der Hersteller MUSS während der Entwicklung des Produktes sicherheitsrelevante Quellcode-Reviews oder automatisierte sicherheitsrelevante Quellcode-Scans durchführen.
Der Hersteller MUSS während der Entwicklung des Produktes automatisierte Sicherheitstests durchführen.
Der Hersteller MUSS einen Schulungsplan zur regelmäßigen Schulung von Entwicklern in sicherer Entwicklung und Secure-Coding-Techniken dokumentieren und umsetzen.
Der Hersteller MUSS alle Entwickler des Produktes in sicherer Entwicklung und Secure-Coding-Techniken schulen. Hierzu MUSS der Hersteller sicherstellen, dass alle Entwickler zu Beginn der Entwicklung geschult sind. Er SOLL für diese anschließend auch laufende Weiterbildung durchführen.
Der Hersteller MUSS den verwendeten sicheren Produktlebenszyklus und deren Teilprozesse dokumentieren und auf Nachfrage der gematik zur Verfügung stellen. Die Dokumentation soll mindestens die folgenden Sicherheitsaktivitäten beschreiben:
ML-123623 - Nur Verbindungen mit zugelassenen TI-Messenger-Clients
Der Messenger-Proxy MUSS prüfen, ob sich der TI-Messenger-Client als von der gematik zugelassenes Produkt ausweisen kann. Verbindungen mit nicht zugelassenen Clients MÜSSEN unterbunden werden.
[<=]
ML-124882 - Kein Einbringen vertraulicher Informationen in Room-States durch Organisationsadministratoren
Anbieter von Home-Servern MÜSSEN sicherstellen, dass sie als Organisations-Administratoren keine sensiblen Informationen in Room-States einbringen. Ebenso MÜSSEN sie Organisations-Administratoren von Homeservern unter Kundenverwaltung informieren, dass im Room-State sichtbare Informationen gegenwärtig nicht verschlüsselt sind. Sobald durch die geplante Matrix-Spec-Changes (MSCs) die Möglichkeit geschaffen wurde vertrauliche Informationen sicher im Room-State zu speichern, wird dies direkt durch die Matrix-Spezifikation abgedeckt.
[<=]
Im TI-Messenger-Kontext werden gemäß [gemSpec_TI_Messenger-Dienst#Akteure und Rollen] zwischen folgenden Rollen unterschieden:
Tabelle 1: Authentifizierung von Nutzerrollen
| Rolle | Matrix-Homeserver | VZD-FHIR-Directory |
|---|---|---|
| User-HBA | Authentifizieren mittels des vereinbarten Authentifizierungsverfahren |
Schreibzugriff: HBA (C.HP.AUT) Lesezugriff: Matrix-OpenID-Token |
| User | Lesezugriff: Matrix-OpenID-Token | |
| Org-Admin | Schreibzugriff: SMC-B (C.HCI.AUT) Lesezugriff: Matrix-OpenID-Token |
Der TI-Messenger-Dienst MUSS die Verifikation von Nutzern mittels SMC-B und HBA unterstützen. Ein TI-Messenger-Client oder Frontend eines Registrieungs-Dienstes MUSS am Smartcard IDP-Dienst der gematik gemäß [gemSpec_IDP_FD] registriert sein.
Im Rahmen der Registrierung werden notwendige Claims (bestätigte Identifikationsmerkmale durch den Nutzer), auf den damit zu nutzenden Dienst festgelegt. Sowohl der TI-Messenger-Client, der Matrix-Homeserver der Messenger-Services als auch der VZD-FHIR-Directory MÜSSEN den ausgestellten Security Tokens (ID_TOKEN, ACCESS_TOKEN) des Smartcard IDP-Dienst vertrauen. Der Anbieter des TI-Messenger-Fachdienstes MUSS über einen organisatorischen Prozess beim Smartcard IDP-Dienst folgende Claims im ACCESS_TOKEN vereinbaren:
Tabelle 2: Inhalte der Claims für SMC-B/HBA
| Leistungserbringerinstitutionen (SMC-B) | Inhalte der Claims für Leistungserbringer (HBA) |
|---|---|
|
|
Die ProfessionOID gibt an um welche Art von Leistungserbringer (z. B. Arzt, Zahnarzt etc.) es sich handelt. Die idNummer beinhaltet die Telematik-ID für Organisationen des Gesundheitswesens und Leistungserbringer.
Der Anbieter des TI-Messenger-Fachdienstes MUSS über einen organisatorischen Prozess beim Smartcard IDP-Dienst für die Autorisierungsanfrage folgende scope-Parameter vereinbaren: scope=openid,VZD-FHIR-Directory
Die Verwaltung der Nutzersession MUSS wie in der in der Matrix-Spezifikation beschrieben erfolgen.
Für die Namensauflösung der vom TI-Messenger-Fachdienst angebotenen Außenschnittstellen, werden DNS-Server im Internet verwendet. Der vereinbarte Abfrage-Record MUSS durch den jeweiligen TI-Messenger-Anbieter bereitgestellt werden und MUSS in öffentlichen DNS-Servern eingetragen sein.
Wird bei der Nutzung eines Messenger-Service für eine Organisation eine auf die Domain der Organisation bezogene Benamung gewählt, erfolgt die Eintragung der notwendigen DNS-Records auf DNS-Server im Internet durch die Administration der Organisation.
Identifizierung von Messenger-Services
Jeder Messenger-Service wird durch einen Matrix-Homeservernamen identifiziert, der aus einem Hostname und einem optionalen Port besteht. Weitere Informationen finden sich in [Federation API#3].
Produkttests zur Sicherstellung der Konformität mit der Spezifikation sind vollständig in der Verantwortung der Anbieter/Hersteller des TI-Messenger-Fachdienstes. Die gematik konzentriert sich bei der Zulassung auf das Zusammenspiel der Produkte durch E2E- und IOP-Tests.
Die eigenverantwortlichen Produkttests bei den Industriepartnern umfassen:
Die Hersteller der TI-Messenger-Fachdienste MÜSSEN zusichern, dass die gematik die Produkttests der Industriepartner in Form von Reviews der Testkonzepte, Testspezifikationen, Testfälle sowie mit dem Review der Testprotokolle (Log- und Trace-Daten) überprüfen kann.
Die gematik fördert eine enge Zusammenarbeit und unterstützt Industriepartner dabei, die Qualität der Produkte zu verbessern. Dies erfolgt durch die Organisation früher IOP-Tests, die Synchronisierung von Meilensteinen und regelmäßige industriepartnerübergreifenden Test-Sessions. Die Test-Sessions umfassen gegenseitige IOP- und E2E Tests.
Die gematik stellt eine TI-Messenger-Fachdienst Referenzimplementierung zur Verfügung. Zur Sicherstellung der Interoperabilität zwischen verschiedenen TI-Messenger-Fachdiensten innerhalb des TI-Messenger-Dienstes MUSS der TI-Messenger-Fachdienst eines TI-Messenger-Anbieters gegen die Referenzimplementierung (TI-Messenger-Client und TI-Messenger Fachdienst) getestet werden.
ML-124200 - Test des TI-Messenger-Fachdienstes gegen die Referenzimplementierung
Der Anbieter des TI-Messenger-Fachdienstes MUSS den Fachdienst gegen die Referenzimplementierung erfolgreich testen. Die Testergebnisse sind der gematik vorzulegen.
[<=]
Die gematik testet in den Zulassungsverfahren auf Basis von Anwendungsfällen. Dabei werden die Anwendungsfälle durchgespielt und es wird versucht viele Funktionsbereiche und Teile der Anwendung mit einzubeziehen. Anschließend wird mit den IOP Tests die Interoperabilität zwischen den verschiedenen Anbieter nachgewiesen. Für das Zulassungsverfahren des TI-Messenger-Dienstes MÜSSEN die TI-Messenger-Clients und TI-Messenger-Fachdienste bereitgestellt werden. Um einen automatisierten Test für den TI-Messenger-Dienst zu ermöglichen, MUSS die Test-App des TI-Messenger-Clients zusätzlich ein Testtreiber-Modul beinhalten, welcher die Funktionalitäten der produktspezifischen Schnittstelle des TI-Messenger-Clients über eine standardisierte Schnittstelle von außen zugänglich macht und einen Fernzugriff ermöglicht.
Der Betrieb des Fachdienstes wird durch den TI-Messenger-Anbieter verantwortet. Entsprechend dem Betriebskonzept [gemKPT_Betr#Anbieterkonstellationen], KANN der Betrieb jedoch aus- bzw. verlagert werden. Zum Beispiel für ein on-premise Hosting. Die Koordination der jeweiligen Komponenten sowie die Erfüllung der Anforderungen verbleiben jedoch am Anbieter. Dieser KANN in Abstimmung mit seinen Nutzern und Dienstleistern Verträge abschließen um den sicheren Betrieb aufrecht zu erhalten.
Der TI-Messenger Fachdienst MUSS mit einer vollumfänglich-funktionalen Verfügbarkeit von 98% betreibbar sein.
Der Anbieter TI-Messenger MUSS sein Produkt TI-Messenger-Fachdienst mit einer vollumfänglich-funktionalen Verfügbarkeit von 98% betreiben.
Wenn der Betrieb von Homeservern on-premise bei den Nutzern realisiert wird, KANN der Anbieter TI-Messenger für diese Produktinstanzen von den Performancevorgaben in Abstimmung mit seinen Nutzern abweichen. Die Abweichungen und die betroffenen Instanzen MÜSSEN der gematik im Rahmen der betrieblichen Prozesse bekannt gemacht werden.
Die folgenden technischen Kommunikationsbeziehungen bzw. Use Cases MÜSSEN im Rahmen des Monitorings und der Rohdatenerfassung am TI-Messenger-Fachdienst erfasst und automatisiert und anonymisiert an die gematik zur Performancebewertung der Vorgaben zum Rohdatenreporting [gemSpec_Perf#Performance-Evaluierung auf der Basis von Rohdaten] reportet werden.
Tabelle 3 : Technische Kommunikationsbeziehungen – Use-Case-Mapping
| Use-Case-Referenz | Use-Case-Titel | Matrix-Operation bzw. Use-Case-Mapping auf TI-Messenger Fachdienst-Komponente(n) |
Start und Ende der Messung am TI-Messenger-Fachdienst |
|---|---|---|---|
| AF_10057 | Anmeldung eines Nutzers am Messenger-Service | Messenger-Service | Start: Messenger Service erhält Login Request durch Client Ende: Übermittlung Matrix-OpenID-Token |
| AF_10060 | Messenger-Service bereitstellen | Registrierungs-Dienst, Messenger-Service | Start: AuthZ, Erstelle Messaging-Service Ende: Account Daten wurden übermittelt |
| AF_10061 | TI-Messenger Remote Invite | Homeserver A, Messenger-Proxy A, Homeserver B, Messenger-Proxy B |
Start Provider A: Eingang Request von Client A: Invite User B + PASSporT Ende: Ausgang Request an Provider B: Invite User B + PASSporT Start Provider B: Eingang Request von Provider A: Invite User B + PASSporT Ende: Versand Invite Request an Client B |
| AF_10062 | Message senden (Remote) | Homeserver A, Messenger-Proxy A, Homeserver B, Messenger-Proxy B |
Start Provider A: Eingang Request von Client A Ende: Ausgang Request an Provider B Start Provider B: Eingang Request von Provider A Ende: Ausgang Request an Client B |
| AF_10063 | Client-Fachdienst-Nachrichtenversand | Matrix CS API spec 8.6 "PUT /_matrix/client/r0/rooms/{roomId}/state/ {eventType}/{stateKey}" |
Start: Eingang Request am Homeserver vom Client. Ende: Response an Client, dass die Nachricht erfolgreich erhalten wurde. |
| AF_10063 | Client-Fachdienst-Nachrichtenempfang | Matrix CS API spec 8.5 "PUT /_matrix/client/r0/rooms/{roomId}/state/ {eventType}/{stateKey}" |
Start: Beginn des Nachrichtenabrufs durch Client Ende: (erfolgreiche) Übermittlung der Nachricht an Client |
| AF_10062 | Fachdienst-Fachdienst-versendete PDUs | siehe Matrix Server-Server-API 4, vgl. synapse Metrik: `synapse_federation_client _sent_pdu_destinations:total` |
Start: Request an Empfangsserver Ende: (erfolgreiche) Übermittlung der Nachricht an Empfangsserver |
| AF_10062 | Fachdienst-Fachdienst-empfangene PDUs | siehe Matrix Server-Server-API 5.1, vgl. synapse Metrik: `synapse_federation_server _received_pdus` |
Start: Eingang des Requests am Empfangsserver Ende: (erfolgreiche) Übermittlung der Nachricht am Empfangsserver |
Bestandsdaten
Der TI-Messenger Fachdienst MUSS die nachfolgenden Informationen jeweils monatlich zum 01. des Monats in folgendem JSON Format als HTTP Body an die Betriebsdatenerfassung (BDE) gemäß gemSpec_SST_LD_BD liefern:
{
„Abfragezeitpunkt“: <Zeitstempel der Abfrage als String im ISO 8601 Format>,
„CI_ID“: <CI ID des abgefragten Fachdienstes gemäß TI-ITSM als String>,
„TIM-FD_Anzahl_Homeserver“: <Anzahl der zum Abfragezeitpunkt instanziierten Homeserver>,
„TIM-FD_Anzahl_Organisationen“: <Anzahl der zum Abfragezeitpunkt registrierten Organisationen>
„TIM-FD_Anzahl_Nutzer“: <Anzahl der zum Abfragezeitpunkt registrierten Nutzer>,
„TIM-FD_Anzahl_aktNutzer“: <Anzahl der zum Abfragezeitpunkt innerhalb des letzten Monats aktiven Nutzer>
}
Da bei dieser Lieferung keine Datei übermittelt wird, sondern der Text direkt im Body, ist für diese Lieferung die Angabe des filenames im HTTP Header gemäß [A_17112] (Tab_I_LogData_002 Operation I_LogData::fileUpload) in der gemSpec_SST_LD_BD NICHT notwendig.
Service Monitoring
Der TI-Messenger Anbieter MUSS das Service Monitoring der gematik technisch-organisatorisch unterstützen.
Dafür kann es z.B. notwendig sein, dass entsprechende Accounts auf Homeservern eingerichtet werden. Das Service Monitoring SOLL dabei zu keinen technischen Veränderungen an den Produkten führen.
Im folgenden Kapitel wird der TI-Messenger-Fachdienst bezogen auf seine Teilkomponenten funktional beschrieben. Der TI-Messenger-Fachdienst ist die Kernkomponente des TI-Messenger-Dienstes. Dieser stellt alle Schnittstellen bereit, die für die Kommunikation innerhalb des TI-Messenger-Dienstes benötigt werden.
In der folgenden Abbildung ist der TI-Messenger-Fachdienst mit seinen Funktionsmerkmalen als Whitebox dargestellt:
Abbildung 3: Funktionaler Aufbau des TI-Messenger-Fachdienstes
Die in der Abbildung grün dargestellten Boxen zeigen die Schnittstellen, die am TI-Messenger-Fachdienst aufgerufen werden. Rot dargestellte Boxen zeigen die Schnittstellen, über die der Fachdienst weitere Services anderer Komponenten nutzt. Eine Ausnahme bildet die Kommunikation zwischen den TI-Messenger-Fachdiensten. Hier wird die Kommunikation bilateral zwischen den zur Föderation gehörenden Fachdiensten realisiert.
Im folgenden Abschnitt wird für die zum TI-Messenger-Fachdienst gehörenden Komponenten, die Nutzung der von der Matrix-Foundation beschriebenen APIs dargestellt. Die jeweilige API MUSS vollständig und als RESTful API gemäß
umgesetzt werden.
Die Abbildung "Matrix-API des Messenger Service" zeigt die jeweils zu berücksichtigenden Schnittstellen bei den bereitzustellenden Komponenten (Server-Server API , Client-Server API, Push Gateway API) an.
Abbildung 4: Matrix-API des Messenger-Service
Die Webservices der Matrix-Homeserver werden nicht direkt von den TI-Messenger-Clients aufgerufen. Der Aufruf der Client-Server-API am Matrix-Homeserver erfolgt über den Messenger-Proxy. Dieser leitet alle Aufrufe der TI-Messenger-Clients an den Matrix-Homeserver per HTTP-Forward weiter. Die Kommunikation der Matrix-Homeserver untereinander erfolgt ebenfalls über den Messenger-Proxy. Auch hier wird die Kommunikation durch Forwarding für die Matrix-Server-Server-Kommunikation zum Homeserver weitergeleitet. Zum Versenden von Push-Notifications nutzt der Matrix-Homeserver die Matrix-Push-Gateway-API des Push-Gateways.
Der Messenger-Proxy agiert neben der Funktion als Proxy zur Weiterleitung aller Server-Server-API- und Client-Server-API-Aufrufe an den Homeserver als Kontrollinstanz, um für die Kommunikation notwendigen Rechte zu prüfen. Hierfür MUSS der Messenger-Proxy für alle Server-Server- und Client-Server-API-Endpunkte genutzt werden.
Im folgenden Kapitel werden alle für den Betrieb des TI-Messenger-Fachdienstes notwendigen Komponenten funktional beschrieben.
Der Matrix-Homeserver MUSS die Matrix-Spezifikation vollständig umsetzen. Bereits existierende Produkte, die der Matrix Spezifikation folgen, können als Matrix-Homeserver verwendet werden, sofern die zusätzlichen vorausgesetzten MSCs:
implementiert wurden.
Der Matrix-Homeserver eines Messenger-Service:
Die vom Matrix-Homeserver verwendeten Authentifizierungsverfahren MÜSSEN konfigurierbar sein. Beim Anmeldeversuch eines neuen TI-Messenger-Nutzers an einem Matrix-Homeserver MUSS dieser alle unterstützten Authentifizierungsverfahren zur Auswahl anbieten. Nach einer erfolgreichen Anmeldung eines TI-Messenger-Nutzers bei dem Matrix-Homeserver stellt dieser ein von ihm erstelltes Matrix-ACCESS_TOKEN sowie ein Matrix-OpenID-Token bereit. Das Matrix-ACCESS_TOKEN wird für jede weitere Autorisierung am Matrix-Homeserver verwendet. Das ausgestellte Matrix-OpenID-Token wird für eine spätere Authentisierung am FHIR-Proxy des VZD-FHIR-Directory verwendet und MUSS eine Gültigkeitsdauer von 30 Minuten aufweisen.
Im Folgenden ist eine Beispielkonfiguration eines Matrix-Homeservers dargestellt:
Beispielkonfiguration eines Synapse Servers
| acme: bind_addresses: - '::' - 0.0.0.0 enabled: false port: 80 reprovision_threshold: 30 url: https://acme-v02.api.letsencrypt.org/directory alias_creation_rules: - action: allow alias: '*' user_id: '*' allow_guest_access: false app_service_config_files: [] autocreate_auto_join_rooms: true bcrypt_rounds: 12 database: args: cp_max: 10 cp_min: 5 database: synapse host: /var/run/postgresql password: min_32_recommended user: synapse name: psycopg2 dynamic_thumbnails: false enable_group_creation: true enable_metrics: true enable_registration: false event_cache_size: 10K expire_access_token: false federation_rc_concurrent: 3 federation_rc_reject_limit: 50 federation_rc_sleep_delay: 500 federation_rc_sleep_limit: 10 federation_rc_window_size: 1000 form_secret: min_32_alphanumeric_recommended key_refresh_interval: 1d listeners: - bind_addresses: - '::' - 0.0.0.0 port: 8008 resources: - compress: true names: - client - compress: false names: - federation type: http x_forwarded: true - bind_addresses: - 0.0.0.0 port: 9001 type: metrics log_config: /opt/synapse/log.config macaroon_secret_key: min_32_alphanumeric_recommended max_image_pixels: 32M max_spider_size: 10M max_upload_size: 23M media_store_path: /opt/synapse/media_store no_tls: true old_signing_keys: {} password_config: enabled: true password_providers: - config: algorithm: HS512 allow_registration: true require_expiracy: true secret: min_32_alphanumeric_recommended module: token_authenticator.TokenAuthenticator perspectives: servers: matrix.org: verify_keys: ed25519:auto: key: Noi6WqcDj0QmPxCNQqgezwTlBKrfqehY1u2FyWP9uYw pid_file: /opt/synapse/synapse.pid public_baseurl: https://matrix-client.meine-arztpraxis.hausaerzte-berlin.de push: include_content: false rc_login: account: burst_count: 10 per_second: 1 address: burst_count: 100 per_second: 10 rc_message_burst_count: 10.0 rc_messages_per_second: 0.2 # optional, for using synapse workers redis: enabled: false host: redis_host password: min_128_alphanumeric_recommended port: 6379 registration_shared_secret: min_32_alphanumeric_recommended report_stats: true report_stats_endpoint: https://synapse-stats.gematik.de/push room_prejoin_state: additional_event_types: - m.room.type - de.gematik.ti-messenger.passport disable_default_event_types: false server_name: meine-arztpraxis.hausaerzte-berlin.de signing_key_path: /opt/synapse/tls/meine-arztpraxis.hausaerzte-berlin.de.signing.key soft_file_limit: 0 thumbnail_sizes: - height: 32 method: crop width: 32 - height: 96 method: crop width: 96 - height: 240 method: scale width: 320 - height: 480 method: scale width: 640 - height: 600 method: scale width: 800 tls_certificate_path: /opt/synapse/tls/meine-arztpraxis.hausaerzte-berlin.de.crt tls_fingerprints: [] tls_private_key_path: /opt/synapse/tls/meine-arztpraxis.hausaerzte-berlin.de.key track_appservice_user_ips: false trusted_third_party_id_servers: [] turn_allow_guests: true turn_shared_secret: min_64_recommended turn_uris: - turns:matrix-voip.tim-provider.de:3478?transport=udp - turns:matrix-voip.tim-provider.de:3478?transport=tcp turn_user_lifetime: 2h uploads_path: /opt/synapse/uploads url_preview_enabled: true url_preview_ip_range_blacklist: - 127.0.0.0/8 - 10.0.0.0/8 - 172.16.0.0/12 - 192.168.0.0/16 - 100.64.0.0/10 - 169.254.0.0/16 - ::1/128 - fe80::/64 - fc00::/7 url_preview_url_blacklist: - username: '*' - netloc: google.com - netloc: '*.google.com' - netloc: twitter.com - netloc: '*.twitter.com' - netloc: t.co - netloc: '*.t.co' use_presence: true |
|---|
ML-123905 - Umsetzung von BSI-Vorgaben für Server (Produkt)
Der TI-Messenger-Fachdienst SOLL den Vorgaben von [BSI-ISI-Server] folgen.
[<=]
ML-123956 - Umsetzung von BSI-Vorgaben für Server (Anbieter)
Der TI-Messenger-Anbieter SOLL den Vorgaben von [BSI-ISI-Server] folgen.
[<=]
Der Messenger-Proxy ist eine Kernkomponente der dezentralen Messenger-Services. Alle Anfragen der TI-Messenger-Clients und anderen Messenger-Services zum Matrix-Homeserver MÜSSEN über den Messenger-Proxy geleitet werden. Die TLS-Kommunikation zwischen den TI-Messenger-Clients und den Matrix-Homeserver MUSS am Messenger-Proxy terminiert werden. Die Absicherung der TLS-Kommunikation MUSS durch eine einseitige Serverauthentisierung unter Nutzung eines X.509-Zertifikats erfolgen.
Die Kommunkation zwischen TI-Messenger-Client und Matrix-Homeserver erfolgt immer über den Messenger-Proxy (Forwarding).Der Messenger-Proxy MUSS sowohl als Reverse Proxy als auch als Forward Proxy fungieren. Alle eingehenden Kommunikationen MUSS der Messenger-Proxy an den Matrix-Homeserver weiterleiten. Eine Kommunikation vom Matrix-Homeserver zum TI-Messenger-Client und auch zu einem anderen Matrix-Homeserver bei einem anderen Messenger-Service MUSS über den Messenger-Proxy weitergeleitet werden.
Für alle Server-to-Server Anfragen (Anfragen, deren Pfad unter /_matrix/federation liegt) MUSS beim anfragenden Matrix-Homeserver im Messenger-Proxy geprüft werden, ob der Zielhomeserver der Anfrage Teil der Föderation ist. Hierfür MUSS MSC3383 (https://github.com/matrix-org/matrix-doc/pull/3383) implementiert und das destination-Feld im Authorization-Header des HTTP Requests geprüft werden. Wenn der Server an der Föderation teilnimmt, darf der Request abgesendet werden, wobei eine Authentisierung des Zielhomeservers gemäß [Federation API#4.2] beschrieben mittels TLS Zertifikat durchgeführt werden muss. Für eingehende Server-to-Server Anfragen MUSS der Messenger-Proxy eine Authentisierung gemäß [Federation API#4.1] beschrieben durchführen. Sobald der Homeserver damit authentisiert wurde, MUSS validiert werden, dass der Homeserver an der Föderation teilnimmt.
Die Prüfung, ob ein Matrix-Homeserver an der Föderation teilnimmt, basiert auf der Domain. Eine Liste an aktuell verifizierten und zugelassenen Domains kann vom VZD-FHIR-Directory über den Registrierungs-Dienst angefragt werden. Wie die Domains vom Registrierungs-Dienst an die Messenger-Proxies verteilt werden ist nicht konkreter spezifiziert.
Beim Aufruf von 2 RESTful-Endpunkten auf den Matrix-Homeservern über den Messenger-Proxy prüft dieser Inhalte wie folgt:
Invite-Endpunkt (Punkt 12 Server-Server API)
Der Messenger-Proxy MUSS Prüfregeln unterstützen. Hierfür agiert der Messenger-Proxy als eine Prüfinstanz, wie folgend beschrieben. Handelt es sich bei der Anfrage um ein Invite-Event MUSS der Messenger-Proxy folgende Prüfregeln anwenden:
Die Kommunikation zum Registrierungs-Dienst MUSS durch TLS abgesichert werden.
Im Folgenden wird ein Beispiel für einen Invite-Event gezeigt.
| { "content": { "avatar_url": "mxc://example.org/SEsfnsuifSDFSSEF", "displayname": "Alice Margatroid", "membership": "invite" }, "event_id": "$143273582443PhrSn:example.org", "origin_server_ts": 1432735824653, "room_id": "!jEsUZKDJdhlrceRyVU:example.org", "sender": "@orig:example.org", "state_key": "@dest:example.org", "type": "m.room.member", "unsigned": { "age": 1234, "invite_room_state": [ { "content": { "token": "<PASSporT>" }, "sender": "@orig:example.org", "state_key": "@dest:example.org", "type": "de.gematik.ti-messenger.passport" }, { "content": { "join_rule": "invite" }, "sender": "@orig:example.org", "state_key": "", "type": "m.room.join_rules" } ] } } |
|---|
Profiles Endpunkt (Punkt 11.2 Client-Server API)
Der Messenger-Proxy MUSS verhindern, dass Nutzer den eigenen Displaynamen ändern können. Der Displayname darf nur durch einen Nutzer in der Rolle Org-Admin geändert werden.
Der PASSporT-Service des Messenger-Service stellt für einen Nutzer ein Personal Assertion Token (PASSporT) gemäß [RFC 8225] aus, wenn die Nutzung des PASSporT-Service des VZD-FHIR-Directory nicht möglich ist. Das ist z. B. der Fall, wenn der relevante Kommunikationspartner nicht im VZD-FHIR-Directory eingetragen ist. Welche Kommunikationsmöglichkeiten zwischen den jeweiligen Nutzer möglich sind wird in [gemSpec_TI-Messenger-Dienst#3.3] beschrieben.
In der folgenden Tabelle sind alle Ressourcen mit den jeweiligen HTTP-Methoden dargestellt. Die jeweilige Operation ist eine Abstraktion auf einen Webservice Endpunkt.
Tabelle 4: Schnittstelle - PASSporT-Service
| Operation | URI | Methode | Request | Response | Beschreibung |
|---|---|---|---|---|---|
| get_passport | /user/{mxid} | GET | string <MXID> |
string <PASSporT> |
liefert ein für den anfragenden Nutzer ausgestelltes PASSporT |
Es ist folgender Endpunkt zu verwenden:
| servers: |
- GET /_matrix/client/unstable/de.gematik.tim.passport/user/{mxid}
Vor der Herausgabe des PASSporT durch den PASSporT-Service sind die Berechtigungen der beabsichtigten Teilnehmer zu prüfen. Dies betrifft zum einen die Berechtigung eines Nutzers die beabsichtigte Kommunikationsbeziehung aufzubauen und zum anderen, ob die übergebene MXID eines Nutzers einen in der Föderation enthaltenen Messenger-Service ausweist. Sollte es bei der Prüfung zu einem Fehler kommen, MÜSSEN die folgenden Fehlercodes verwendet werden.
Tabelle 5 Error-Code PASSporT-Service
| Error-Code | Beschreibung |
|---|---|
| 403 Forbidden | der Nutzer ist nicht berechtigt ein PASSporT für den Invite auszulösen |
| 404 Not Found | die übergebe MXID ist nicht von einem Nutzer innerhalb der Föderation |
| 503 Service Unavailable | der PASSporT-Service ist nicht erreichbar |
| 500 Internal Server Error | interner Server Error |
Aufbau des PASSporT
Der Aufbau des PASSporT MUSS wie im [RFC 8225] beschrieben erfolgen. Die Befüllung der gezeigten Header Elemente MUSS wie im [RFC 8225] gefordert erfolgen und wie folgt aufgebaut sein:
| Header: { "typ":"passport", "alg":"ES256", "x5u":"https://cert.example.org/passport.cer" } |
|---|
Das Erstellen des PASSporT MUSS durch den PASSporT-Service des beabsichtigten Kommunikationspartners erfolgen. Die TI-Messenger-spezifischen PASSporT-Claims sind durch den PASSporT-Service wie folgt zu befüllen. Der Claim mit dem Bezeichner "orig" ist die MXID des Nutzers, der das invite auslösen wird. Diese MXID wird durch den Nutzer an den gewünschten Kommunikationspartner übergeben. Der Claim "dest" wird mit der MXID des damit einzuladenden Nutzers befüllt. Das folgende Beispiel zeigt eine solche Struktur.
| Claims: { "orig": { "uri": "matrix:u/me:example.org" }, "dest": { "uri": [ "matrix:u/you:example.org" ] } } |
|---|
Das erzeugte PASSporT wird durch den PASSporT-Service mit einem Zertifikat aus der Komponenten PKI der TI signiert und anschließend an den TI-Messenger Client übergeben, der das invite auslöst. Die Zertifikate haben die keyUsage = digitalSignature.
Zur besseren Veranschaulichung dient die folgende Darstellung:
Tabelle 6: Ablauf PASSporT-Erstellung
| Client A | Client B |
|---|---|
| 1: Client A übergibt seine MXID an den Client B |
|
| 2: Client B nimmt MXID von A und übergibt diese an den PASSporT-Service seines Messenger-Service <get_passport> | |
| 3: PASSporT-Service von B erzeugt PASSporT mit: „dest“: MXID von Nutzer B „Orig“: MXID von Nutzer A |
|
| 4: PASSporT wird von B an den Client A übergeben | |
| 5: Nutzer A löst invite an Nutzer B aus |
Der Registrierungs-Dienst MUSS ein Frontend oder Schnittstellen bereitstellen, damit ein interoperabler Onboarding-Prozess für die Registrierung von Messenger-Services gewährleistet wird. Der Registrierungs-Dienst MUSS es ermöglichen einen neuen Messenger-Service über ein Frontend zu erzeugen. So MUSS der Registrierungs-Dienst bei einer neuen Registrierungsanfrage automatisiert den durch den Smartcard IDP-Dienst ausgestellten ACCESS_TOKEN (gemäß Kapitel 4.2.1) validieren, einen dezentralen Messenger-Service automatisiert starten und die entsprechende Matrix-Domain (referenziert zur im Claim genannten Organisation) im VZD-FHIR-Directory hinterlegen.
Für die Aufnahme eines TI-Messenger-Fachdienstes in die Föderation des TI-Messenger-Dienstes wird durch den Registrierungs-Dienst die Matrix Domain einer Organisation in das VZD-FHIR-Directory eingetragen. Der Registrierungs-Dienst eines TI-Messenger-Fachdienst MUSS sich gegenüber dem VZD-FHIR-Directory mittels OAuth2 Client Credentials Flow authentifizieren und ebenfalls als Anbieter auf dem VZD-FHIR-Directory gelistet sein. Der Registrierungs-Dienst MUSS die Domains der dezentralen Messenger-Services, referenziert auf die entsprechende Organization-Ressource als Endpoint hinterlegen. Genauere Angaben sind im VZD-FHIR-Directory Datenmodell zu finden.
Der Registrierungs-Dienst MUSS eine Liste aller verifizierten Domains aus dem VZD-FHIR-Directory für die dezentralen Messenger-Proxies bereitstellen. Dazu wird die im VZD-FHIR-Directory bereitgestellte Operation GET/FederationList aufgerufen. Um die Schnittstelle nutzen zu können MUSS sich der Registrierungs-Dienst des TI-Messenger-Anbieters, wie bereits oben erwähnt, mit einem Accesstoken authentisieren, das vom OAuth-Server des VZD-Anbieters ausgestellt wurde. Mit der Operation GET/FederationList MUSS die Liste der an der TI-Messenger-Föderation beteiligten Matrix-Domainnamen abgefragt werden. Die Abfrage der FederationList MUSS mindestens einmal am Tag erfolgen. Die Prüfung auf Aktualität dieser Föderationsliste beim VZD-FHIR-Directory MUSS bei jeder Anfrage durch einen Matrix-Proxy zur Bereitstellung der Föderationsliste erfolgen. Nach dem Erhalt dieser Liste MUSS diese durch den Messenger-Proxy für die Prüfung der Domainzugehörigkeit genutzt werden. Der Registrierungs-Dienst MUSS für den Abruf dieser FederationList durch die Messenger-Proxy eine Schnittstelle bereitstellen. Als Ergebnis erhält der Registrierungs-Dienst eine Liste der hashes der an der Föderation beteiligten Domainnamen.
Vor der Ausgabe eines PASSporT durch den PASSporT-Service im VZD-FHIR-Directory wird dieser vom PASSporT-Service signiert. Der Registrierungs-Dienst des TI-Messenger-Fachdienstes MUSS für die Prüfung der Gültigkeit dieser Signatur durch die Messenger-Proxies die dafür benötigten Zertifikate mit dem öffentlichen Schlüssel des PASSporT-Services im VZD-FHIR-Directory über die Operation GET/PASSporTCertificate vom VZD-FHIR-Directory abfragen und für die spätere Nutzung durch die Messenger-Proxies abspeichern. Der Registrierungs-Dienst MUSS für den Abruf dieses PASSporTCertificate durch die Messenger-Proxies eine Schnittstelle bereitstellen.
Der TI-Messenger-Fachdienst MUSS einen Push-Gateway, gemäß Matrix-Spezifikation, für den TI-Messenger-Client bereitstellen. Es obliegt den TI-Messenger-Anbietern der einzelnen TI-Messenger-Clients, ob eine Push-Funktion unterstützt wird.
| Kürzel |
Erläuterung |
|---|---|
| API | Application Programming Interface |
| AuthN | Authentication |
| AuthZ | Authorization |
| CC | Common Criteria |
| DSGVO | Datenschutz-Grundverordnung |
| FHIR | Fast Healthcare Interoperable Resources |
| HBA | Heilberufsausweis |
| HTTP | Hyptertext Transfer Protocol |
| IDP | Identity Provider |
| JSON | JavaScript Object Notation |
| KVNR | Krankenversichertennummer |
| MSC | Matrix Spec Change |
| MXID | Matrix-ID |
| OAuth | Open Authorization |
| PASSporT | Personal Assertion Token |
| SMC-B | Institutionenkarte (Security Module Card Typ B) |
| SSSS | Secure Secret Storage and Sharing |
| TI | Telematikinfrastruktur |
| TLS | Transport Layer Security |
| UIA | User Interactive Authorization |
| VZD | Verzeichnisdienst |
| Begriff |
Erläuterung |
|---|---|
| MXID | Eindeutige Identifikation eines TI-Messenger-Nutzers (Matrix-User-ID) |
| on-premise | Das Produkt wird auf eigener oder gemieteter Hardware betrieben |
| Relying Party |
Vertraurungswürdige Komponente, die Zugriff auf eine sichere Anwendung ermöglicht |
| X.509-Zertifikat | Ein Public-Key-Zertifikat nach dem X.509-Standard |
Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.
| [Quelle] |
Herausgeber: Titel |
|---|---|
| [gemGlossar] | gematik: Einführung der Gesundheitskarte – Glossar |
| [gemKPT_TI_Messenger] | gematik: Konzeptpapier TI-Messenger |
| [gemSpec_TI_Messenger-Dienst] | gematik: Spezifikation TI-Messenger-Dienst |
| [gemKPT_Betr] | gematik: Betriebskonzept Online-Produktivbetrieb |
| [gemSpec_Perf] | gematik: Übergreifend Spezifikation Performance und Mengengerüst TI-Plattform |
| [gemSpec_Krypt] | gematik: Übergreifende Spezifikation Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur |
| [gemSpec_IDP_FD] | gematik: Spezifikation Identity Provider – Nutzungsspezifikation für Fachdienste |
| [Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
|---|---|
| [Matrix Foundation] |
Matrix Foundation https://matrix.org/docs/spec/ |
| [Federation API] | Matrix Foundation https://matrix.org/docs/spec/server_server/r0.1.4 |
| [RFC 8225] | PASSporT: Personal Assertion Token https://datatracker.ietf.org/doc/html/rfc8225 |
| [OpenID] | OpenID Foundation https://openid.net/developers/specs/ |
| [OWASP Proactive Control] | OWASP Proactive Controls https://owasp.org/www-project-proactive-controls/ |
| [MSC 3013] | https://github.com/matrix-org/matrix-doc/pull/3013 |