Elektronische Gesundheitskarte und Telematikinfrastruktur

Konzept TI-Föderation

Version
1.0.0
Revision
1666101
Stand
10.07.2026
Status
freigegeben
Klassifizierung
öffentlich
Referenzierung
gemKPT_TI-Foderation

Dokumentinformationen

Gender-Hinweis
Aus Gründen der besseren Lesbarkeit wird in diesem Dokument überwiegend die männliche Form verwendet. Sämtliche Personenbezeichnungen gelten gleichermaßen für alle Geschlechter.

Änderungen zur Vorversion

Es handelt sich um eine Erstveröffentlichung.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das Dokument beschreibt den Aufbau der TI-Föderation gemäß des Standards [OpenID Federation 1.1]. Die TI-Föderation ist der Vertrauensraum für eine Anwendungslandschaft im Gesundheitsheitswesen. Ziele dieses Vertrauensraums sind

• die Erhöhung der Sicherheit in der Kommunikation der Teilnehmer des Vertauensraum untereinander durch Einsatz etablierter und standardisierter Identifikations- und Authentisierungsverfahren
• die Reduktion der Komplexität von notwendigen Vertrauensbeziehungen durch Bildung von Vertrauensketten
• die Nutzung standardisierter Features zur Umsetzung von Vertrauensregeln (Policies) und Nachweisen (Trust Marks)

Die TI-Föderation bildet die Möglichkeit Technologie unabhängig die Authentifizierung von Anwendungen und Nutzern in einem Vertrauensraum abzubilden.

Das Dokument bündelt alle Informationen, die zuvor auf die Spezifikationsdokumente und andere öffentlich verfügbaren Dokumente der gematik zur TI-Föderation verteilt waren. Das Dokument soll als zentrales Dokument zur TI-Föderaton fortgeschrieben werden.

1.2 Zielgruppe

Das Dokument richtet sich an

• Hersteller, die Komponenten der TI-Föderation herstellen
• Anbieter, die Komponenten der TI-Föderation betreiben
• Architekten der gematik für das Verständnis des Vertrauensraums und die potentielle Nutzung für die Produkte der TI 2.0
• Sicherheitsexperten der gematik zur Bewertung der IT-Sicherheit der Gesundheitsanwendungen in der TI-Föderation
• Betriebsexperten der gematik zur Bewertung und Erfassung betrieblicher Rahmenbedingungen und Anforderungen
• Aufsichtsbehördern und Gesellschafter zur fachlichen und technischen Bewertung

1.3 Geltungsbereich

Wichtiger 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.

1.4 Abgrenzung des Dokuments

Diese Dokument enthält keine konkreten Anforderungen an ein Produkt der TI-Föderation. Diese Anforderungen sind in den Spezifikationsdokumenten der Produktypen [gemSpec_IDP_FedMaster] und [gemSpec_IDP_Sek] sowie in [gemSpec_IDP_FD] zur Berücksichtigung in den Produkttypen der Fachdienste beschrieben. 

Das Dokument beschreibt nicht allumfassend, wie Komponenten außerhalb der TI-Föderation mit den Komponenten der TI-Föderation interagieren bzw., wie Artefakte (beispielsweise ID-Token, Access-Token) außerhalb der TI-Föderation zu verwenden sind.

1.5 Methodik

1.5.1 Technische Beschreibung

Das Dokument beschreibt die technischen Konzepte der TI-Föderation auf verschiedenen Abstraktionsebenen:

• Beteiligte technische Systeme und deren Aufgaben
• Schnittstellen zwischen den Systemen
• Schnittstellen zu Systemen außerhalb der TI-Föderation
• Schnittstellen zu Nutzern

Die technische Beschreibung erfolgt auf verschiedenen Granularitätsebenen mit unterschiedlichen Sichten auf die Gesamtarchitektur.

1.5.2 Normative Festlegungen

Das Konzeptdokument enthält keine normativen Festlegungen. Die normativen Festlegungen der beteiligten Systeme sind in den betreffenden Spezifikationen beschrieben:

• gemSpec_IDP_FedMaster - Anforderungen an Trust Anchor und Intermediate (Superior Entity) und allgemeine Anforderungen an Teilnehmer der TI-Föderation
• gemSpec_IDP_Sek - Anforderungen an sektorale Identity Provider (OpenID Provider)
• gemSpec_IDP_FD - Anforderungen an Fachdienste als OpenID-Relying-Party und (OAuth) Protected Resource

1.5.3 Hinweis auf offene Punkte <<optional, nur bis einschl. Abstimmphase >>

2 Fachliche & technische Rahmenbedingungen

2.1 Fachliche Grundlagen

2.1.1 Begriffsbestimmungen

Zum weiteren Verständnis ist es notwendig zunächst die wesentlichen Begrifflichkeiten zu klären.

Identität: Eine Identität ist eine Menge von Identitätsattributen, die einer [Person oder Organisation] zugeordnet sind. Eine eindeutige Identität ist eine Identität, die innerhalb eines bestimmten Anwendungskontextes die zugehörige Entität eindeutig repräsentiert, unterschiedliche Entitäten haben unterschiedliche eindeutige Identitäten. Eine Identität (das heißt eine Menge von Identitätsattributen), die innerhalb eines Anwendungskontextes eindeutig ist, ist dies nicht notwendigerweise auch in einem anderen Kontext. (BSI TR-03107)

Attribut: Ein Identitätsattribut oder ein Identitätsdatum ist eine Charakteristik oder eine Eigenschaft einer Entität. Beispiele für Identitätsattribute einer natürlichen Person sind Name, Geburtsdatum oder die Eigenschaft, ein bestimmtes Alter erreicht zu haben. Identitätsattribute von Behörden umfassen etwa Bezeichnung der Behörde oder deren Webadresse. (BSI TR-03107)

Authentisierung/Authentifizierung: „Authentifizierung“ ist ein elektronischer Prozess, der die Bestätigung der elektronischen Identifizierung einer natürlichen oder juristischen Person oder die Bestätigung des Ursprungs und der Unversehrtheit von Daten in elektronischer Form ermöglicht. (eIDAS)

Eine Authentisierung ist das Versehen einer Identität oder anderer übermittelter Daten mit Metadaten, die es einer vertrauenden Entität ermöglichen, die Herkunft, Echtheit und Gültigkeit der Identität oder der Daten zu überprüfen. Der Überprüfungsvorgang durch die vertrauende Entität ist die Authentifizierung der Identität/der Daten. (BSI TR-03107)

Authentisierungsmittel: Authentisierungsmittel sind technische Mittel, die es dem Inhaber erlauben, eine Identität (das heißt eine Menge von Identitätsattributen) oder andere Daten zu authentisieren. Beispiele für Authentisierungsmittel sind Passwörter, der Personalausweis oder kryptographische Token. Sind mehrere technische Mittel notwendig (etwa Chipkarte und PIN), so besteht das vollständige Authentisierungsmittel aus mehreren Authentisierungsfaktoren. (BSI TR-03107).

Multifaktor-Authentisierung: Multifaktor-Authentisierung ist eine Form der Authentisierung, bei welcher zur Identitätsbestätigung mehrere unabhängige Merkmale (Faktoren) überprüft werden. Üblicherweise werden für eine Zwei-Faktor-Authentisierung unterschiedliche Merkmale aus Wissen, Besitz, Biometrie, Standort miteinander kombiniert. Am häufigsten kommt im Bereich der mobilen Anwendungen die Kombination aus Faktor Besitz (repräsentiert durch das Smartphone) und Faktor Biometrie (z. B. durch FaceID oder TouchID) bzw. Faktor Wissen (z. B. eine PIN) zum Einsatz.

Enrolment: Das Enrolment ist die Registrierung einer Entität in einem Authentisierungssystem, meist verbunden mit einer Identitätsprüfung, die in der Ausgabe von Authentisierungsmitteln mündet. (BSI TR-03107)

Identifizierung: Eine Identifizierung ist die Übermittlung von anwendungsbezogen geeigneten Identitätsattributen (einer Identität), einschließlich authentisierender Metadaten (Authentisierung), sowie die Überprüfung (Authentifizierung) dieser Identität durch die vertrauende Entität. (BSI TR-03107)

Identifizierungsdiensteanbieter: Diensteanbieter, deren Dienst darin besteht, für einen Dritten eine einzelfallbezogene Identifizierungsdienstleistung mittels des elektronischen Identitätsnachweises nach § 18 zu erbringen (§ 2 Abs. 3a PAuswG).

Autorisierung: Die Autorisierung einer Entität ist die Zuordnung und Überprüfung von Rechten zu einer Entität, zum Beispiel Zugriffsrechte oder das Recht, eine bestimmte Anwendung zu nutzen. Eine Autorisierung erfolgt immer anwendungsbezogen […]. (BSI TR-03107)

2.1.2 Technische Grundlagen

Für ein grundlegendes Verständnis des Konzeptes des föderierten Identitätsmanagements werden in diesem Kapitel zunächst die Grundlagen des eingesetzten Authentifizierungsprotokolls und die relevanten technischen Parameter kurz erläutert. Unter einem Authentifizierungsprotokoll versteht man im Allgemeinen eine Reihe an Befehlen, die zur Verifizierung einer Nutzeridentität zwischen zwei Entitäten verwendet werden. Für unterschiedliche Einsatzszenarien haben sich verschiedene Authentifizierungsprotokolle und De-Facto-Standards etabliert. Im Rahmen der Mensch-zu-Gerät-Authentisierung in der Telematikinfrastruktur wird das sog. OpenID Connect Protokoll verwendet, welches auf dem sog. OAuth 2.0-Standard basiert und diesen um Informationen zur Identität über Attribute erweitert.

OAuth 2.0: Hinter dem Begriff verbirgt sich ein Autorisierungsdienst, welcher es einem registrierten Nutzer ermöglicht, die Kontrolle über die Art und den Umfang der von ihm erteilten Freigaben zu steuern. Der Nutzer kann mittels OAuth der anfragenden Anwendung (dem sog. „Client“) erlauben, auf Daten des Nutzers auf einem Resource-Server (z. B. Bilder, Dokumente, u.ä.) zuzugreifen. Dazu authentisiert ein Authorization Server den Nutzer z. B. mit username + Passwort und fordert von ihm die Erlaubnis (Consent) für den Zugriff des Client auf die Resource ein. Für den Zugriff auf die Daten des Nutzers vom Resource-Server erhält der Client ein Access-Token, welches dieser bei jedem Aufruf des Resource-Server mit übertragen muss. Vor Herausgabe der Daten prüft der Resource-Server durch eine Abfrage beim Authorization Server, ob die Datenherausgabe an den Client legitim ist. OAuth 2.0 unterstützt scopes (Gruppe von Informationen), allerdings ohne diese weiter zu benennen. OAuth 2.0 kümmert sich ausschließlich um die Autorisierung von Zugriffen durch einen Nutzer, nicht aber um dessen Authentifizierung.

OpenID Connect (OIDC): Der OIDC-Standard erweitert OAuth 2.0 um die Fähigkeit der Nutzer-Authentisierung. Neben dem Zugriffstoken (Access-Token) liefert die Erweiterung OIDC nach erfolgreicher Nutzer-Authentisierung einen ID-Token, welche Informationen (claims) zum Nutzer selbst enthält. Claims sind Eigenschaftsattribute (z. B. der Vorname oder die Mailadresse). Die Zusammenfassungen von claims zu logischen Gruppen werden als scopes bezeichnet. Diese Identitätsdaten des Nutzers werden von einem Identity Provider in dem ID-Token verpackt und als JSON Web Token (JWT) einem anfragenden Client zur Verfügung gestellt.

OpenID Federation: OpenID Federation [OpenID Federation 1.1] standardisiert den Aufbau eines Vertrauensraums für Anwendungen im Internet. Anwendungen können sich nach Vorgaben des Standards in so einem Vertrauensraum registrireren. Technologieunabhängig legt der Standard fest, wie Vertrauensbeziehungen zwischen den Anwendungen des Vertrauensraums erstellt und geprüft werden. Je nach eingesetzter Technologie werden in weiter führenden Spezifikationen, aufbauend auf den dort zugrunde liegenden technischen Standards, Erweiterungen für die Integration in einen OpenID Federation Vertrauensraum beschrieben ([OpenID Federation for OpenID Connect 1.1], [OpenID Federation for Wallet Architectures 1.0]). 

Die TI-Föderation bildet so einen Vertrauensraum nach [OpenID Federation 1.1]. Da die dort registrierten Anwendungen über OpenID Connect (OIDC) kommunizieren, kommt in der TI-Föderation [OpenID Federation for OpenID Connect 1.1] und die zugrunde liegenden Standards zum Einsatz. Perspektivisch kann der Vertrauensraum der TI-Föderation um Anwendungen erweitert werden, die auf der Wallet-Architektur der dort zugrunde liegenden Standards aufsetzen. Hier ist dann die Erweiterung des OpenID Federation Standards [OpenID Federation for Wallet Architectures 1.0] zu berücksichtigen.

2.1.3 Identifikationsmittel und -systeme

Die Identifizierung des Nutzers kann je nach Schutzbedarf und Regulierungsniveau der verwendeten Anwendung auf unterschiedliche Weise erfolgen. Gesundheitsdaten weisen nach DSGVO einen besonders schützenswerten Charakter auf. Folglich muss zweifelsfrei sichergestellt sein, dass ein Zugriff nur durch berechtigte Personen möglich ist. Hierfür gibt es in Deutschland unterschiedliche hoheitliche Identifikationssysteme mit einer jeweiligen Zweckbindung. Sie dienen dazu, eine Person oder ein Objekt eindeutig innerhalb eines Nutzungskontextes zu identifizieren. Im Kontext des Gesundheitswesens dient die Gesundheitskarte mit zugehöriger Krankenversichertennummer als Identifikationsmittel mit entsprechender Zweckbindung. Diese kann über einen Chip entweder kontaktbehaftet oder mit NFC Funktionalität und einem auf ihr enthaltenen Lichtbild für Vor-Ort-Identifizierung bzw. eine PIN für eine Identifizierung online und vor Ort eingesetzt werden. Des Weiteren stellt der neue Personalausweis bzw. der elektronische Aufenthaltstitel bzw. die ID-Karte für EU/EWR-Bürger/innen mit integrierter eID-Funktionalität ein universell einsetzbares Identifikationssystem dar. Zu dessen digitaler Verwendung muss die zugehörige PIN durch den Nutzer freigeschaltet werden. Auf Basis des Personalausweises existieren unterschiedliche Identifizierungsverfahren. Das sicherste Verfahren ist das Online-Ausweisident-Verfahren, bei welchem das Auslesen des Datensatzes mittels NFC-Schnittstelle über die Eingabe der PIN abgesichert wird.

2.2 Die Ausgangslage im deutschen Gesundheitswesen

Die Telematikinfrastruktur (TI) ist die Plattform für Gesundheitsanwendungen in Deutschland. Millionen Versicherte profitieren durch die digitalen Anwendungen der TI von einer verbesserten medizinischen Versorgung. Ziel und Aufgabe der gematik ist es, diese Infrastruktur auszubauen, zu modernisieren und so fit für das digitale Gesundheitswesen der Zukunft zu machen.

Im Jahr 2005 wurde mit dem Aufbau der Telematikinfrastruktur durch die gematik begonnen. Mit dem Whitepaper zur Telematikinfrastruktur 2.0 wurde 2020 von der gematik ein Impuls veröffentlicht, die TI als zukunftsfähige Arena für digitale Medizin voranzutreiben.

Die Architektur der TI 2.0 basiert demnach auf sechs fundamentalen Säulen:

1. Einem föderierten Identitätsmanagement, weil mit dieser "Brücke" mehr Flexibilität und Nutzerfreundlichkeit durch die einfache Nutzung von Identitätsbestätigungen der TI für eigene digitale Angebote der Nutzergruppen möglich ist.
2. Der universellen Erreichbarkeit der Dienste, weil der Wegfall proprietärer IT-Lösungen (z. B. Konnektor) Kosten senkt und den Betrieb stabilisiert.
3. Einer modernen Sicherheitsarchitektur, weil diese die eigenständige Bereitstellung von Diensten durch unterschiedliche Anbieter ermöglicht und sowohl sicherer als auch effizienter ist.
4. Verteilten Diensten, weil aus Sicht optimierter Versorgungsprozesse die Verknüpfung von Daten aus verschiedenen Quellen notwendig ist.
5. Interoperabilität und strukturierte Daten, weil die anwendungsfallbezogene Versorgung und Forschung eine Verbesserung der Datenqualität erfordert. Standardbasierte strukturierte Daten und Schnittstellen erhöhen die Verfügbarkeit bei Produkten und Services.
6. Einem automatisiert verarbeitbaren Regelwerk der TI, weil eine automatisierte Überprüfung der Sicherheit und des Datenschutzes sowie der Interoperabilität und Verfügbarkeit das Vertrauen in die TI stärken.

Das vorliegende Dokument beschreibt die Grundlagen für die erste Säule, das föderierte Identitätsmanagement.

Zum Verständnis dieser Säule werden im weiteren Verlauf dieses Kapitels die grundlegenden Bausteine des Identitätsmanagements im Gesundheitswesen vorgestellt und, soweit erforderlich, erläutert.

2.2.1 Identitätsherausgeber, Identitätsträger und Trust Service Provider

Unter Identitätsherausgebern versteht man diejenigen Instanzen, die die Datenhoheit über die digitalen Identitäten und die ihnen zugeordneten Attribute besitzen. Für die verschiedenen Sektoren existieren unterschiedliche Identitätsherausgeber, deren Zuständigkeiten im SGB V geregelt sind. In jedem Sektor existieren spezifische Identitätsträger, die in der Telematikinfrastruktur 1.0 durch Smartcards repräsentiert werden.

Ergänzend zu kartenbasierten Identitäten sollen mit der TI 2.0 digitale Identitäten bereitgestellt werden. Dadurch wird Nutzern die Möglichkeit eröffnet, neben der kartenbasierten Authentifizierung auch eine Authentifizierung mittels digitaler Identitäten zu nutzen. Das Konzept der TI-Föderation sieht sowohl die Nutzung von Smartcards als auch die Verwendung digitaler Identitäten als Authentifizierungsmittel für TI-Fachdienste vor.

Im gesetzlichen Versichertensektor fungieren die gesetzlichen Krankenkassen als Identitätsherausgeber. Sie geben für ihre Versicherten die elektronische Gesundheitskarte (eGK) als Identitätsträger aus. Die rechtliche Grundlage hierfür bildet § 291 SGB V. In Deutschland existieren derzeit rund 95 gesetzliche Krankenkassen (Stand: 01.01.2026). Jede Krankenkasse ist für die Ausgabe der Identitätsträger an ihre Versicherten eigenständig verantwortlich. Die Ausgabe elektronischer Gesundheitskarten durch private Krankenversicherungen oder sonstige Kostenträger erfolgt lediglich in wenigen Ausnahmefällen.

Im Leistungserbringerbereich ist die Herausgabe von Identitäten – insbesondere die Ausgabe elektronischer Heilberufs- und Berufsausweise sowie von Komponenten zur Authentifizierung von Leistungserbringerinstitutionen – in § 340 SGB V geregelt. In der praktischen Umsetzung ergibt sich daraus die Zuständigkeit der Kammern auf Landesebene (z. B. Landesärztekammern, Landeszahnärztekammern, Psychotherapeutenkammern, Apothekerkammern und Handwerkskammern) für die Ausgabe elektronischer Heilberufsausweise. Darüber hinaus übernehmen die gematik und das elektronische Gesundheitsberufsregister (eGBR) für ausgewählte Berufsgruppen die Rolle des Identitätsherausgebers. Insgesamt ergeben sich damit für den Identitätsträger eHBA rund 100 Identitätsherausgeber.

Die Ausgabe der SMC-B als Identitätsträger für Leistungserbringerinstitutionen erfolgt sektorspezifisch durch die Kassenärztlichen Vereinigungen, die Kassenzahnärztlichen Vereinigungen, die Apothekerkammern, die Deutsche Krankenhaus TrustCenter und Informationsverarbeitung GmbH (DKTIG), die gematik, das elektronische Gesundheitsberufsregister sowie die Handwerkskammern. Für den Identitätsträger SMC-B agieren damit insgesamt rund 70 Identitätsherausgeber.

Im Rahmen der Bereitstellung von Identitätsträgern werden bei Bedarf sogenannte Trust Service Provider (TSP) eingebunden. Ein Trust Service Provider bzw. Vertrauensdiensteanbieter ist eine Organisation, die digitale Zertifikate ausstellt und verwaltet. Diese Zertifikate dienen der Erstellung und Validierung elektronischer Signaturen sowie der Authentifizierung von Personen und Organisationen.

Elektronische Gesundheitskarte (eGK)

Die elektronische Gesundheitskarte (eGK) ist eine personenbezogene Smartcard und dient seit Anfang 2015 als ausschließlicher Krankenversicherungsnachweis für gesetzlich Versicherte. Sie speichert kryptographische Schlüssel sowie die zugehörigen Zertifikate zur Authentisierung gegenüber der Telematikinfrastruktur (TI). Gemäß § 291 Absatz 2 Nummer 3 SGB V ermöglicht die eGK – sofern sie nach dem 1. Januar 2023 ausgestellt wurde – die Speicherung von Daten nach § 291a Absatz 2 Nummer 1 bis 3 und 6 SGB V.

Elektronischer Heilberufsausweis (HBA)

Der elektronische Heilberufsausweis (eHBA) ist eine personenbezogene Smartcard, die an Leistungserbringer wie Ärztinnen und Ärzte, Zahnärztinnen und Zahnärzte sowie Apothekerinnen und Apotheker ausgegeben wird. Er enthält das kryptographische Schlüsselmaterial sowie die zugehörigen Zertifikate zur Authentisierung gegenüber der Telematikinfrastruktur (TI). Darüber hinaus ermöglicht der eHBA die Erstellung qualifizierter elektronischer Signaturen, beispielsweise für die Ausstellung von E-Rezepten, die Signatur von KIM-Nachrichten, Notfalldaten und elektronischen Arztbriefen. Zudem kann er für die Ver- und Entschlüsselung sowie die Umschlüsselung von Nachrichten verwendet werden.

Institutionsbezogene Identität SM(C)-B

Die Security Module Card Typ B (SMC-B) ist eine institutionsbezogene Identität, die einer Organisation innerhalb der Telematikinfrastruktur (TI) zugeordnet ist. Sie wird entweder als Smartcard oder in Form eines Zertifikatsbündels bereitgestellt und stellt Zertifikate für die Authentisierung sowie für die Ver-, Ent- und Umschlüsselung von Daten und elektronische Signaturen bereit. 

GesundheitsID

Die GesundheitsID ist die digitale Identität für Versicherte im Gesundheitswesen, die von der jeweiligen Krankenkasse bereitgestellt wird. Sie dient zur Anmeldung an Anwendungen der Telematikinfrastruktur (TI) sowie an weiteren versorgungsrelevanten Fachdiensten und kann perspektivisch auch als Versicherungsnachweis – analog zur elektronischen Gesundheitskarte (eGK) – genutzt werden.

Unter einer GesundheitsID wird ein Datensatz im sektoralen Identity Provider (IDP) der Krankenkasse verstanden, der dort für einen Versicherten angelegt ist. Für die Anlage einer GesundheitsID muss der Versicherte einen Identifizierungsprozess durchlaufen.

Auf Anfrage eines Fachdienstes und nach erfolgreicher Authentifizierung des Versicherten stellt der sektorale IDP der Krankenkasse ein ID-Token mit den für den jeweiligen Fachdienst erforderlichen Informationen aus dem Datensatz der GesundheitsID aus.

2.2.2 Der Weg zur TI 2.0

Die drei genannten Smartcard-Typen stellen in der Telematikinfrastruktur 1.0 die primären Identitätsträger dar. Die ausschließliche Verwendung kartenbasierter Identitätsträger bringt jedoch eine Reihe von Nachteilen und Einschränkungen mit sich. Zu den wesentlichen Grenzen zählen insbesondere:

• Smartcards schränken die Benutzerfreundlichkeit ein, insbesondere bei der Nutzung mobiler Endgeräte.
• In mobilen Szenarien hängt die Einsetzbarkeit von Smartcards von der vorhandenen Gerätehardware ab, insbesondere vom Vorhandensein und der Positionierung eines NFC-Moduls.
• Änderungen an Rollen oder Attributen, die in Zertifikaten auf Smartcards hinterlegt sind, lassen sich nur mit erheblichem Aufwand umsetzen. Für neue Nutzergruppen müssen entsprechende Smartcards zunächst durch die Identitätsherausgeber und Vertrauensdiensteanbieter (TSP) bereitgestellt werden. Insbesondere vor dem Hintergrund bestehender Lieferengpässe bei Hardware und Chipkarten stellt dies eine erhebliche Einschränkung bei der Anbindung neuer Nutzergruppen dar.
• Die Wiederbeschaffung und Neuausgabe von Smartcards ist mit langen Vorlauf- und Lieferzeiten verbunden, insbesondere infolge der anhaltenden Engpässe bei Chipkarten.

Auch auf Seiten des Gesetzgebers wurden diese Einschränkungen erkannt und die Einführung digitaler Identitäten gesetzlich vorgesehen. Die Konzeption der digitalen Identitäten verfolgt das Ziel, sämtliche relevanten Anwendungsfälle der Authentisierung zu adressieren, die bislang durch den Einsatz von Smartcards abgedeckt werden. Darüber hinaus sollen die bestehenden Anwendungsfälle um zusätzliche Einsatzszenarien erweitert werden, die durch digitale Identitäten ermöglicht werden.

Ergänzend kommen in der Telematikinfrastruktur mit der gSMC-K und der gSMC-KT zwei gerätespezifische Sicherheitsmodulkarten zum Einsatz. Diese finden jedoch im Kontext des föderierten Identitätsmanagements keine Anwendung und werden daher im Folgenden nicht weiter betrachtet.

2.2.3 Gesetzliche Rahmenbedingungen

In diesem Kapitel wird ein Überblick über die wichtigsten rechtlichen Grundlagen der vorliegenden Konzeption gegeben. Der Überblick erhebt keinen Anspruch auf Vollständigkeit. Mit Inkrafttreten des Krankenhauspflegeentlastungsgesetzes (KHPflEG) zum 1. Januar 2023 wurden die §§ 291 und 340 SGB V geändert. Die hieraus resultierenden Neuerungen werden in diesem Kapitel bereits berücksichtigt.

Die Begründung der verpflichtenden Einführung der digitalen Identitäten im Gesundheitswesen findet sich im fünften Sozialgesetzbuch. Hier heißt es:

„Spätestens ab dem 1. Januar 2024 stellen die Krankenkassen den Versicherten ergänzend zur elektronischen Gesundheitskarte auf Verlangen eine sichere digitale Identität für das Gesundheitswesen barrierefrei zur Verfügung, die die Vorgaben nach Absatz 2 Nummer 1 und 2 erfüllt und die Bereitstellung von Daten nach § 291a  Absatz 2 und 3 durch die Krankenkassen ermöglicht.“ (§291 Absatz 8 Satz 1 SGB V).

Eine analoge Vorgabe für Leistungserbringer und deren Institutionen findet sich in Paragraph 340:

„(6) Spätestens ab dem 1. Januar 2024 haben die Stellen nach Absatz 1 Satz 1 Nummer 1 sowie den Absätzen 2 und 4 ergänzend zu den Heilberufs- und Berufsausweisen auf Verlangen des Leistungserbringers eine digitale Identität für das Gesundheitswesen zur Verfügung zu stellen, die nicht an eine Chipkarte gebunden ist“ (§340 Absatz 6 Satz 1 SGB V).

„(7) Spätestens ab dem 1. Januar 2025 haben die Stellen nach Absatz 1 Satz 1 Nummer 3 sowie den Absätzen 2 und 4 ergänzend zu den Komponenten zur Authentifizierung von Leistungserbringerinstitutionen auf Verlangen der Leistungserbringerinstitution eine digitale Identität für das Gesundheitswesen zur Verfügung zu stellen, die nicht an eine Chipkarte gebunden ist.“ (§340 Absatz 7 Satz 1 SGB V).

Des Weiteren definieren die jeweiligen Paragraphen die Rolle der Verantwortlichkeiten:

„Die Gesellschaft für Telematik legt die Anforderungen an die Sicherheit und Interoperabilität der digitalen Identitäten fest. Die Festlegung der Anforderungen an die Sicherheit und den Datenschutz erfolgt dabei im Benehmen mit dem Bundesamt für Sicherheit in der Informationstechnik und der oder dem Bundesbeauftragen für den Datenschutz und die Informationsfreiheit auf Basis der jeweils gültigen Technischen Richtlinien des Bundesamts für Sicherheit in der Informationstechnik und unter Berücksichtigung der notwendigen Vertrauensniveaus der unterstützten Anwendungen.“ (§291 Absatz 8 Satz 3 und 4 SGB V bzw. sinngemäß §340 Absatz 8 Satz 1 und 2 SGB V).

Sowohl für digitale Identitäten für Versicherte nach § 291 Abs. 8 SGB V als auch für Leistungserbringende und Leistungserbringerinstitutionen nach § 340 Abs. 8 SGB V muss das '[...] Sicherheits- und Vertrauensniveau der Ausprägung einer digitalen Identität [...] mindestens dem Schutzbedarf der Anwendung entsprechen, bei der diese eingesetzt wird (§ 291 Absatz 8 Satz 6 bzw. § 340 Absatz 8 Satz 4 SGB V, gleichlautend).

Mit den Änderungen des KHPflEG wurde des Weiteren Satz 7 in §291 SGB V aufgenommen: "Abweichend von Satz 6 kann der Versicherte nach umfassender Information durch die Krankenkasse über die Besonderheiten des Verfahrens in die Nutzung einer digitalen Identität einwilligen, die einem anderen angemessenen Sicherheitsniveau entspricht." (§291 Absatz 8 Satz 7 SGB V)

Die entsprechenden Technischen Richtlinien des Bundesamts für Sicherheit in der Informationstechnik beziehen sich auf:

• BSI TR-03107-1 Elektronische Identitäten und Vertrauensdienste im E-Government
• BSI TR-03147 Vertrauensniveaubewertung von Verfahren zur Identitätsprüfung natürlicher Personen.

Gesundheitsdaten zählen gemäß DSGVO zu den besonders schützenswerten personenbezogenen Daten. Daraus resultieren erhöhte Anforderungen an Datenschutz und Informationssicherheit. Entsprechend ist das Vertrauensniveau gemäß TR-03107-1 als hoch einzustufen.

Darüber hinaus ergeben sich aus der Verordnung über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt (eIDAS-Verordnung) weitere Anforderungen an die Bereitstellung digitaler Identitäten und Vertrauensdienste.

2.3 Fachliche Einordnung der sektoralen Identity Provider

Aufbau, Funktionsumfang und Schnittstellen der Identity Provider sollen im Rahmen einer Föderation den Zugang zur Telematikinfrastruktur als Alternative zu kartengebundenen Identitäten ermöglichen.

Abbildung 1 : Idee des Aufbaus einer TI-Föderation auf Basis des OpenID Federation Standards

Unter Föderation versteht sich, dass jeder Sektor, und innerhalb der Sektoren die jeweiligen Identitätsherausgeber einen eigenen Identity Provider für dessen Mitglieder bereitstellt. Bei den digitalen Identitäten für den Sektor „Versicherte“ stellen die Kostenträger, sprich die gesetzlichen und die privaten Krankenversicherungen jeweils eigene Identity Provider zur Verfügung, über welchen sich deren Versicherte gegenüber den Diensten der TI und Krankenversicherung eigenen sowie weiteren Gesundheitsanwendungen authentisieren können. Dabei ist es auch möglich, dass mehrere Institutionen auf freiwilliger Basis einen gemeinsamen IDP bereitstellen. Die Anforderungen an die Identity Provider der unterschiedlichen Sektoren unterscheiden sich. Dies liegt vor allem darin begründet, dass die Anwendungsfälle und Anwendungen, welche eine Authentifizierung eines Nutzers über einen IDP erfordern für Versicherte andere sind als beispielsweise für Ärzte in Praxen und Krankenhäusern oder für andere medizinische Berufe wie Hebammen und Pflegedienste.

Die Orchestrierung der unterschiedlichen Identity Provider innerhalb der Föderation erfolgt über übergeordnete Knotenpunkte (Superior Entities). Der Federation Master als Root bildet den Trust Anchor der TI-Föderation.

Ziel der Föderation ist es, Versicherten einen zentralen Zugang zu relevanten Diensten der Telematikinfrastruktur, zu Anwendungen der Krankenversicherung sowie zu digitalen Gesundheitsanwendungen bereitzustellen. Hierfür authentisieren sich die Nutzer gegenüber ihrem sektoralen Identity Provider, der die erforderlichen Identitäts- und Attributinformationen in Form eines Tokens an die jeweilige Anwendung übermittelt.

Dadurch wird eine nutzerfreundliche und niedrigschwellige Verwendung digitaler Gesundheitsdienste ermöglicht. Gleichzeitig werden die Anwendungen von der Verwaltung von Identitäten und Authentifizierungsprozessen entlastet und können sich auf ihre fachlichen Kernaufgaben konzentrieren.

Das vorliegende Konzept bezieht sich in weiten Teilen auf die digitalen Identitäten und die TI-Föderation für Versicherte. Dieser Teil der TI-Föderation ist bereits spezifiziert, umgesetzt und befindet sich im produktiven Einsatz.

Wie und in welcher Form die TI-Föderation künftig auf Leistungserbringer (LE) und Leistungserbringerinstitutionen (LEI) erweitert wird, ist zum gegenwärtigen Zeitpunkt noch offen.

Das Konzept zeigt jedoch die Möglichkeiten auf, wie die TI-Föderation auf Basis des OpenID Federation-Standards einen Vertrauensraum zwischen den verschiedenen Systemen des Gesundheitswesens schaffen kann, ohne dabei zwingend auf die TI-PKI angewiesen zu sein. Dadurch wird die Nutzung digitaler Identitäten im Gesundheitswesen auch über die heutigen TI-Anwendungen hinaus ermöglicht und gefördert.

2.4 Rahmenbedingungen des Authentisierungs-Flows

2.4.1 Relevante Anwendungen der IDP-Nutzung

Die Einführung digitaler Identitäten in der Föderation ist kein Selbstzweck. Ziel ist es vielmehr, den sicheren und komfortablen Zugang zu den verschiedenen Anwendungen des Gesundheitswesens über eine zentrale Authentifizierung zu ermöglichen. Diese Anwendungen sind vielfältiger Natur. Versicherte können sowohl auf krankenversicherungsspezifische Anwendungen und Funktionen als auch auf Anwendungen zugreifen, die unabhängig von ihrer jeweiligen Krankenversicherung bereitgestellt werden.

Beispiele für solche Anwendungen sind:

• E-Rezept: Versicherte können über die E-Rezept-App der gematik auf ihre elektronischen Rezepte zugreifen. Die Anwendung ist unabhängig von einer konkreten Krankenversicherung und wird zentral durch die gematik für alle Versicherten bereitgestellt. Die entsprechenden Regelungen finden sich in § 360 SGB V. Das E-Rezept zählt zu den zentralen Anwendungen der Telematikinfrastruktur und stellt damit einen der wesentlichen Anwendungsfälle für digitale Identitäten dar. Für den Zugriff auf ihre Rezepte können Versicherte die bei ihrer Krankenversicherung eingerichtete GesundheitsID verwenden.
  
• Digitale Gesundheitsanwendungen: Der Leistungsanspruch auf digitale Gesundheitsanwendungen (DiGA) basiert auf den Regelungen des Digitale-Versorgung-Gesetzes (DVG). In der DiGA-Verordnung ist unter anderem festgelegt, dass DiGA-Hersteller eine Authentifizierung über die sektoralen Identity Provider (IDP) der Krankenversicherungen unterstützen müssen. 
  
• Weitere Anwendungen mit Gesundheitsbezug: Darüber hinaus soll die Nutzung weiterer Anwendungen mit Bezug zum Gesundheitswesen über die sektoralen Identity Provider der Krankenversicherungen ermöglicht werden. So könnte beispielsweise der Zugang zu Versichertenportalen durch eine Authentifizierung über die sektoralen IDP der Krankenversicherungen erfolgen. Die Nutzung dieser Anwendungen ist in der Regel nicht gesetzlich reguliert und liegt im Verantwortungsbereich der jeweiligen Krankenkasse.
  

Darüber hinaus sollen über digitale Identitäten auch krankenkasseneigene Anwendungen für Versicherte nutzbar gemacht werden. Hierfür ist jeweils lediglich eine Authentifizierung über den eigenen sektoralen Identity Provider (IDP) erforderlich. Versicherte anderer Kostenträger müssen in diesem Zusammenhang nicht berücksichtigt werden.

Hierzu zählen insbesondere folgende Anwendungen:

• Elektronische Patientenakte: Die Bereitstellung der elektronischen Patientenakte (ePA) durch die Krankenkassen ist in § 341 SGB V geregelt. Es handelt sich damit um eine krankenkassenspezifische Anwendung, die ausschließlich mit dem jeweiligen sektoralen Identity Provider der betreffenden Krankenkasse kommunizieren muss.
  
• Krankenversicherung eigene Service-Anwendungen: Hierzu zählen beispielsweise Service-Apps, Online-Geschäftsstellen oder Informationsangebote der Krankenkassen. Aus Nutzer- und Wirtschaftlichkeitsgesichtspunkten soll es den Krankenkassen nach eigenem Ermessen möglich sein, auch für diese Anwendungen eine Authentifizierung über ihren sektoralen Identity Provider zu implementieren.
  

Die im Februar 2023 veröffentlichte Spezifikation der gematik adressiert aufgrund der gesetzlichen Rahmenbedingungen vorrangig die Anwendungsfälle E-Rezept, DiGA und ePA. Die Erweiterung des Funktionsumfangs des sektoralen Identity Providers einer Krankenversicherung zur Anbindung weiterer, insbesondere krankenkasseneigener Anwendungen, obliegt dem jeweiligen Kostenträger. Solche Erweiterungen liegen außerhalb des Anwendungsbereichs der gematik-Spezifikation, sofern dadurch keine sicherheitsrelevanten Anforderungen oder regulatorischen Vorgaben beeinträchtigt werden.

Vertrauensniveaus

Das Vertrauensniveau einer Anwendung wird durch den Schutzbedarf der Daten bestimmt, die innerhalb der Anwendung verarbeitet werden. Die Zuordnung zu einem Vertrauensniveau berücksichtigt unter anderem die technische und organisatorische Sicherheit des jeweiligen Verfahrens sowie die geltenden rechtlichen Rahmenbedingungen.

Die zugrunde liegende Technische Richtlinie TR-03107 des Bundesamtes für Sicherheit in der Informationstechnik (BSI) definiert drei Vertrauensniveaus: normal, substantiell und hoch. Die zuvor beschriebenen Fokusanwendungen E-Rezept, DiGA und ePA sind dem Vertrauensniveau hoch zuzuordnen. Folglich konzentriert sich die gematik-Spezifikation auf die Anforderungen dieses Vertrauensniveaus.

Die Unterstützung weiterer Vertrauensniveaus obliegt den jeweiligen Krankenkassen und wird durch die Spezifikation nicht eingeschränkt, sofern dadurch keine sicherheitsrelevanten Anforderungen oder Vorgaben beeinträchtigt werden.

Bereitstellung von Claims

Im Rahmen der Authentifizierung fordern Anwendungen beim Identity Provider (IDP) die für ihre Nutzung erforderlichen Scopes an. Diese setzen sich aus vordefinierten Claims zusammen. Zur Sicherstellung der Interoperabilität mit den Fokusanwendungen E-Rezept, DiGA und ePA wird ein Minimal-Claim-Set definiert. Dieses beschreibt die Menge an Claims, die ein Identity Provider mindestens bereitstellen muss, um als Teilnehmer der Föderation agieren zu können

Zugriffsmedien

Die zuvor beschriebenen Anwendungen sollen über verschiedene Endgeräte und Anwendungstypen nutzbar sein. Grundsätzlich wird dabei zwischen der Nutzung auf Smartphones und auf Desktop-PCs unterschieden. Im Smartphone-Umfeld ist zusätzlich zwischen nativen mobilen Apps und browserbasierten Anwendungen zu differenzieren. Die betrachteten Anwendungen können grundsätzlich sowohl als App als auch als Web-Anwendung bereitgestellt werden.

Hieraus ergeben sich verschiedene Authentifizierungsflüsse, die von den Identity Providern (IDP) unterstützt werden müssen.

• App2App-Flow: Der App2App-Flow beschreibt die Authentifizierung eines Nutzers, bei der sowohl der Fachdienst-Client als auch die Authenticator-App auf demselben Endgerät installiert sind. Dieser Flow kommt beispielsweise zum Einsatz, wenn ein Nutzer die E-Rezept-App auf seinem Smartphone verwendet und sich über die App seiner Krankenversicherung auf demselben Gerät authentifiziert.
  
• Web2App-Flow auf einem Gerät: Der Web2App-Flow beschreibt die Authentifizierung eines Nutzers innerhalb einer Web-Anwendung, die im Browser desselben Geräts ausgeführt wird, auf dem auch die Authenticator-App installiert ist. Ein Beispiel hierfür ist die Nutzung einer DiGA als Web-Anwendung, bei der die Authentifizierung über die App der Krankenversicherung auf demselben Smartphone erfolgt.
  
• Zwei-Geräte-Flow: Der Zwei-Geräte-Flow beschreibt die Authentifizierung eines Nutzers, bei der die Anwendung auf einem anderen Endgerät als die Authenticator-App ausgeführt wird. Hierbei kann es sich sowohl um eine App als auch um eine Web-Anwendung handeln. Ein typisches Beispiel ist der Zugriff auf die elektronische Patientenakte (ePA) über einen Desktop-Browser, während die Authentifizierung über die App der Krankenversicherung auf dem Smartphone erfolgt.
  

2.4.2 Ablauf der Authentisierung

Der konkrete Ablauf der Authentifizierung hängt von den zuvor beschriebenen Rahmenbedingungen ab. Diese bestimmen maßgeblich, auf welche Anwendung über welches Zugriffsmedium und mit welchen Authentifizierungsmitteln zugegriffen werden kann.

Unabhängig von den jeweiligen Rahmenbedingungen kommt das zuvor beschriebene OpenID-Connect-Protokoll zum Einsatz. Nach erfolgreicher Authentifizierung des Nutzers beim Identity Provider (IDP) wird ein ID-Token erzeugt und an den als OpenID-Relying-Party in der Föderation registrierten Fachdienst übermittelt. Das ID-Token enthält die Claims der von der Relying Party angefragten Scopes sowie weitere für die Anwendung relevante Informationen.

Nach Erhalt des ID-Tokens liegt das eigentliche Zugriffsmanagement in der Verantwortung des jeweiligen Fachdienstes. Dieser prüft, welche Berechtigungen und gegebenenfalls Bevollmächtigungen für die im ID-Token beschriebene Entität vorliegen. Das Ergebnis dieser Prüfung mündet in der Ausstellung eines Access-Tokens durch den Authorization Server des Fachdienstes. Über dieses Access-Token erhält der authentifizierte Nutzer die Berechtigung, auf die geschützten Ressourcen (Protected Resources) des Fachdienstes zuzugreifen.

3 Systemüberblick

3.1 Allgemeiner Überblick

Ein zentrales Merkmal der zu entwickelnden Gesamtlösung der sektoralen Identity Provider (IDP) ist das Prinzip der Föderation. Die Funktionalität eines Identity Providers wird dabei nicht durch einen einzelnen zentralen Dienst bereitgestellt, sondern gemeinschaftlich durch eine Vielzahl sektoraler IDP. Für diese sind jeweils die identitätsherausgebenden Institutionen verantwortlich, die auch für die Verwaltung der zugehörigen Nutzergruppen zuständig sind.

Um eine Gesamtlösung zu gewährleisten, die von Anwendungen möglichst einfach genutzt werden kann, sind in bestimmten Bereichen einheitliche technische und organisatorische Vorgaben erforderlich. Hierzu zählen insbesondere:

• Einheitliche Identitätsattribute für die verschiedenen Nutzergruppen (Scopes und Claims),
• einheitliche Verfahren zur Auffindung sektoraler Identity Provider (IDP Discovery),
• eine einheitliche Grundstruktur der Vertrauensbeziehungen innerhalb der Föderation zwischen Fachdiensten und Identity Providern,
• einheitliche Vertrauensniveaus im Rahmen eines gemeinsamen Trust Frameworks.

Die Abbildung „Beispielhafter Aufbau der TI-Föderation“ veranschaulicht eine mögliche Struktur der TI-Föderation. Alle sektoralen Identity Provider der Föderation sind beim Federation Master registriert. Sofern bei einer künftigen Erweiterung der TI-Föderation auf weitere Sektoren signifikant unterschiedliche Anforderungen an die sektoralen Identity Provider entstehen, kann es sinnvoll sein, die Identity Provider einzelner Sektoren unter sogenannten Intermediates zusammenzufassen.

Alle Fachdienste (i.d.R. die Authorization Server der Fachdienste), die die bei den Identity Providern hinterlegten digitalen Identitäten nutzen möchten, sind als OpenID-Relying-Parties beim Federation Master oder einem Intermediate registriert. Die Intermediates sind wiederum entweder bei einem anderen Intermediate oder direkt beim Federation Master registriert.

Hinweis: Abweichend von dem dargestellten Beispiel sind aktuell sämtliche sektoralen Identity Provider sowie die Authorization Server der DiGA-Anwendungen und des OGR direkt beim Federation Master als Teilnehmer der Föderation registriert. Die Spezifikation und Einführung von Intermediates erfolgt erst dann, wenn hierfür ein konkreter Bedarf besteht, beispielsweise zur Durchsetzung sektorspezifischer Policies oder zur Vergabe besonderer Trust Marks für Teilgruppen von Föderationsteilnehmern.

Abbildung 2 : Beispiel des Aufbau der TI-Födeartion

Die TI-Föderation besteht aus verschiedenen Systemen, die über standardisierte Schnittstellen miteinander kommunizieren. Gemeinsam bilden diese Systeme einen Vertrauensraum.

Nutzer verwenden unterschiedliche Fachdienste der Telematikinfrastruktur (TI). Diese werden in Form von Apps oder Browseranwendungen bereitgestellt und bieten spezifische, in der Regel medizinische, digitale Services an.

Zur Authentifizierung der Nutzer greifen die Fachdienste auf die sektoralen Identity Provider (IDP) der Föderation zurück. Die Prüfung der fachlichen Zugriffsberechtigungen und die Entscheidung über die Nutzung eines Fachdienstes erfolgen hingegen durch den jeweiligen Fachdienst. Hierzu wertet dieser die von den sektoralen Identity Providern bereitgestellten Identitäts- und Attributinformationen aus und leitet daraus die für den Nutzer geltenden Zugriffsrechte ab.

Die Fachdienste (i.d.R. die Authorization Server der Fachdienste) sind als OpenID-Relying-Parties gemäß [OpenID Federation 1.1]  Bestandteil der TI-Föderation und entsprechend innerhalb des Vertrauensraums registriert.

Als sektoraler Identity Provider (IDP) wird ein Dienst zur Authentifizierung von Nutzern bezeichnet. Nach erfolgreichem Abschluss des Authentifizierungsprozesses stellt der sektorale IDP Identitätsinformationen über den Nutzer in Form eines ID-Tokens bereit.

Die bereitgestellten Informationen sind spezifisch für die jeweilige Nutzergruppe und den zugehörigen Sektor innerhalb der Telematikinfrastruktur des Gesundheitswesens. Die vom IDP übermittelten Identitätsinformationen werden vom anfragenden Fachdienst genutzt, um die Berechtigungen des Nutzers zu prüfen und festzustellen, auf welche Fachdaten und Fachprozesse dieser zugreifen darf.

Ein wesentlicher Sektor der TI-Föderation ist der Bereich der Krankenversicherungen mit den Versicherten als Nutzergruppe. Grundsätzlich ist jedoch nicht ausgeschlossen, dass ein sektoraler IDP Identitätsinformationen für mehrere Nutzergruppen bereitstellt (siehe hierzu den Parameter „user_type_supported“ als Claim der Entity Configuration eines sektoralen IDP gemäß [gemSpec_IDP_Sek]).

Die sektoralen Identity Provider sind als OpenID Provider gemäß [OpenID Federation 1.1] ebenfalls Bestandteile der TI-Föderation.

Der Vertrauensraum der TI-Föderation wird durch sogenannte Superior Entities gemäß [OpenID Federation 1.1] aufgespannt. Diese können entweder als Trust Anchor oder als Intermediate ausgeprägt sein. Alle Teilnehmer der TI-Föderation sind bei einer Superior Entity registriert. Nur registrierte Teilnehmer sind berechtigt, die Dienste der TI-Föderation in Anspruch zu nehmen.

Der Trust Anchor der TI-Föderation ist der Federation Master (siehe [gemSpec_IDP_FedMaster]). Er stellt eine zentrale Komponente für alle Teilnehmer der TI-Föderation dar, insbesondere für Intermediates, Fachdienste in ihrer Rolle als OpenID-Relying-Parties sowie sektorale Identity Provider (OpenID Provider).

Intermediates fungieren als Trust Anchor für Teilnehmer mit spezifischen Trust Marks, Policies und Contrains. Beispiele hierfür sind ein ZETA-Intermediate für ZETA-Authorization Server oder ein DiGA-Intermediate für DiGA-Authorization Server.

Neben den als OpenID-Relying-Parties registrierten Fachdiensten (in der Regel deren Authorization Server), sektoralen Identity Providern (OpenID Provider), Intermediates und dem Federation Master als Superior können weitere Komponenten (Entity-Types) Bestandteil der TI-Föderation sein. Hierzu zählen beispielsweise TI-Fachdienste selbst, die gemäß [OpenID Federation 1.1] als OAuth Resource registriert werden.

Die Kommunikation zwischen den Systemen der TI-Föderation basiert auf den Standards OpenID Federation, OpenID Connect (OIDC), OAuth 2.0, JSON Web Token (JWT) sowie weiteren unterstützenden Spezifikationen.

Neben den Komponenten der TI-Föderation sind im Gesamtkontext weitere Systeme über Schnittstellen an die Föderation angebunden, ohne selbst Bestandteil dieser zu sein. Hierzu zählen insbesondere Bestandssysteme, in denen die Identitäts- und Nutzerdaten der Anwender verwaltet und gepflegt werden.

Abbildung 3 : TI-Föderation und Nachbarsysteme 

Anwender / Versicherte: Anwender sind die Versicherten, die einen Fachdienst über ein Frontend des Versicherten (FdV) nutzen möchten. Um einen Fachdienst nutzen zu können, müssen sich die Anwender authentifizieren. Die Authentifizierung mittels GesundheitsID erfolgt dabei über die Komponenten der TI-Föderation. Zur Einwilligung in die Weitergabe ihrer Daten an einen Fachdienst sowie bei der Nutzung eines Authentifizierungsmittels sind die Anwender aktiv in den Authentifizierungsprozess eingebunden.

Fachdienst-Client:  Der Fachdienst-Client ist, in der derzeitigen TI-Föderation, die ausschließlich die Authentifizierung von Versicherten unterstützt, das Frontend des Versicherten (FdV). Anforderungen zur Nutzerauthentifizierung werden vom Fachdienst-Client an eine als OpenID-Relying-Party registrierte Komponente der TI-Föderation übermittelt. Abhängig von der konkreten Umsetzung des Fachdienstes wird das Ergebnis der Authentifizierung anschließend an den Fachdienst-Client zurückgegeben.

Ist die Kommunikation zwischen dem Fachdienst-Client und dem als OpenID-Relying-Party registrierten Backend gemäß dem OAuth-Standard umgesetzt, erhält der Fachdienst-Client ein Access-Token. Darüber hinaus ist die Frontend-Komponente des OpenID Providers, das sogenannte Authenticator-Modul, für die Interaktion mit dem Nutzer während des Authentifizierungsprozesses in ein FdV integriert.

Krankenversicherungsysteme: Die Krankenversicherungssysteme stellen die Datenquellen für die zu authentifizierenden Versicherten dar. Die für die Authentifizierung erforderlichen Daten werden für die sektoralen Identity Providern der Krankenversicherungen aus den jeweiligen Krankenversicherungssystemen bezogen.

Registrierungskomponente: Die Registrierung von Teilnehmern innerhalb der TI-Föderation erfolgt über eine Registrierungskomponente. Derzeit handelt es sich hierbei um einen organisatorischen Prozess mit mehreren beteiligten Organisationen und Systemen. Perspektivisch soll dieser Prozess automatisiert werden.

Certificate Transparency (CT) Logs: Die TI-Föderation nutzt Certificate Transparency (CT) Logs externer Anbieter zur Überprüfung und Nachvollziehbarkeit der von den sektoralen IDPs verwendeten TLS-Zertifikate und öffentlichen Schlüssel.

Ident-Verfahren: Zur sicheren Identifizierung von Versicherten ist die Durchführung eines geeigneten Identifizierungsverfahrens erforderlich. Hierzu können beispielsweise die Online-Ausweisfunktion des Personalausweises, ein Post-Ident-Verfahren oder die elektronische Gesundheitskarte (eGK) in Verbindung mit einer PIN verwendet werden. Gegenüber dem sektoralen Identity Provider wird hierdurch die Identität des Versicherten verifiziert.

3.2 Schnittstellen zu Umsystemen

Tabelle 1 : Schnittstellen zu Umsystemen 

4 Lösungsstrategie

4.1 Anwendungsfälle

Superior Entities (federation_entity) können gemäß [OpenID Federation 1.1] (Kapitel „Introduction“) entweder als Trust Anchor oder als Intermediate fungieren.  Jeder Teilnehmer der TI-Föderation, einschließlich der Superior Entities, veröffentlicht eine Entity Configuration in Form eines Entity Statements. Die zulässigen und erforderlichen Inhalte dieser Entity Statements sind im Standard [OpenID Federation 1.1], insbesondere in den Kapiteln „Claims that MUST or MAY Appear in both Entity Configurations and Subordinate Statements“ sowie „Federation Entity“, definiert.

Superior Entities sind Komponenten der TI-Föderation, die sowohl technische als auch organisatorische Aufgaben innerhalb des Vertrauensraums übernehmen. Hierzu zählen insbesondere die Verwaltung von Vertrauensbeziehungen sowie die Unterstützung föderationsbezogener Prozesse. Die nachfolgenden Anwendungsfälle dienen der Beschreibung der Anforderungen an Superior Entities.

Tabelle 2 : Übersicht über die Anwendungsfälle im Gesamtkontext Federation Master

* Die sektoralen Identity Provider der Krankenversicherungen werden direkt beim Federation Master (TI Trust Anchor) registriert. Bereits bestehende Registrierungen von Fachdiensten als OpenID-Relying-Parties der TI-Föderation beim Federation Master bleiben erhalten. Alle neu zu registrierenden ZETA-Authorization Server werden als OpenID-Relying-Parties der TI-Föderation bei einem ZETA-AS Intermediate registriert. Hierfür muss der ZETA-AS Intermediate beim Federation Master registriert sein. Weitere Intermediates, beispielsweise zur Gruppierung aller DiGA-Authorization Server, können bei Bedarf eingerichtet werden.

** Die Automatisierung der Registrierung erfolgt über ein eigenständiges Produkt, die Registrierungs-Engine. Diese befindet sich derzeit in der Spezifikation. Bis zur Produktivsetzung der Registrierungs-Engine erfolgt die Registrierung von Teilnehmern über einen manuellen Prozess, der über das IT-Service-Management (ITSM) gesteuert wird.

Abbildung 4 : Anwendungsfälle TI-Föderation 

4.2 Aufbau und Kommunikation

Die Struktur und Kommunikation innerhalb der TI-Föderation orientieren sich am Standard [OpenID Federation 1.1] sowie an den dort referenzierten Standards. Die Orientierung an [OpenID Federation 1.1] liefert die grundlegenden Vorgaben und Rahmenbedingungen für den Aufbau des Vertrauensraums der TI-Föderation. Von den Vorgaben des Standards wird nur dort abgewichen, wo dies aufgrund spezifischer Anforderungen der gematik erforderlich ist. Dies erfolgt entweder durch die Konkretisierung optionaler Anforderungen des Standards oder durch dessen Erweiterung und Präzisierung unter Berücksichtigung der Rahmenbedingungen der TI.

Jeder Teilnehmer der TI-Föderation muss eine dem OpenID Federation-Standard entsprechende Entity Configuration in Form eines Entity Statements öffentlich bereitstellen.

Federation Entities (Superior Entities) sind Komponenten des Produkttyps „Federation Master“. Hierzu zählen einerseits der Federation Master selbst als Trust Anchor und andererseits die Intermediates (siehe Abbildung „Beispielhafter Aufbau der TI-Föderation“).

Die Identity Provider (Produkttyp „Sektoraler IDP“) der TI-Föderation stellen sicher, dass ausschließlich identifizierte Nutzer gegenüber anfragenden Fachdiensten authentifiziert werden. Darüber hinaus wird sichergestellt, dass Nutzer der Übermittlung der für die jeweilige Anwendung erforderlichen Daten ausdrücklich zustimmen (Consent).

Die in der TI-Föderation als OpenID-Relying-Parties registrierten Fachdienste beziehungsweise deren Authorization Server nutzen die sektoralen Identity Provider, um Nutzer ihrer Anwendungen eindeutig zu authentifizieren und deren Einwilligung in die Übermittlung erforderlicher Nutzerdaten einzuholen. Die OpenID-Relying-Parties sind Komponenten der jeweiligen Fachdienst-Produkttypen.

Der Vertrauensraum der TI-Föderation wird aufgebaut, indem sich jeder Teilnehmer über einen organisatorischen Prozess innerhalb der TI-Föderation registriert. Diese Erstregistrierung erfolgt unabhängig von den späteren Laufzeitprozessen der Föderation.
Intermediates als Komponenten des Produkttyps „Federation Master“ müssen nicht den organisatorischen Registrierungsprozess durchlaufen. Ihre Registrierung innerhalb des Vertrauensraums der TI-Föderation erfolgt auf technischer Ebene innerhalb des Produkttyps.
Zur Laufzeit kann jeder Teilnehmer prüfen, ob das Kommunikationsgegenüber ebenfalls als Teilnehmer der TI-Föderation registriert ist und über welche Eigenschaften und Berechtigungen es innerhalb der Föderation verfügt. Die Vertraulichkeit und Vertrauenswürdigkeit der Kommunikation werden sichergestellt, indem die Vertrauensbeziehungen entlang der Trust Chain bis zum Trust Anchor der TI-Föderation validiert werden.

Abbildung 5 : Komponenten der TI-Föderation im Überbrlick

Bei der Authentifizierung eines Nutzers gegenüber einer Anwendung ist der Federation Master als Vertrauensanker der TI-Föderation eingebunden. Die Voraussetzung für die Kommunikation zwischen einem Fachdienst in seiner Rolle als OpenID-Relying-Party und einem sektoralen Identity Provider ist deren Registrierung innerhalb des Vertrauensraums der TI-Föderation.

Voraussetzungen für die Prüfung der beteiligten Komponenten im Rahmen eines Nutzungsprozesses sind:

• Die aktuellen Signaturschlüssel des beteiligten sektoralen Identity Providers und der OpenID-Relying-Party wurden im Rahmen des Registrierungsprozesses bei der zuständigen Superior Entity (Federation Master oder Intermediate) hinterlegt.
• Jeder Teilnehmer hat im Rahmen seiner Registrierung den öffentlichen Schlüssel des Federation Masters erhalten, mit dem dessen Entity Statement validiert werden kann.
• Die Entity Statements des beteiligten sektoralen Identity Providers und der OpenID-Relying-Party entsprechen den Vorgaben des Standards [OpenID Federation 1.1].
• Der FQDN des Federation Masters wurde durch den Betreiber des Federation Masters veröffentlicht. Der FQDN entspricht dem eindeutigen Identifier des Federation Masters in der TI-Föderation.

Die nachfolgende Übersichtsgrafik veranschaulicht das Zusammenspiel der verschiedenen Komponenten innerhalb der TI-Föderation.

Die Kommunikation zwischen dem Anwender und dem Fachdienst über das Anwendungsfrontend entspricht in der Regel den Vorgaben von OAuth 2.0 ([RFC6749]) unter Verwendung von Proof Key for Code Exchange (PKCE) gemäß [RFC7636]. Sie ist nicht Gegenstand dieses Dokuments und wird daher nicht näher beschrieben.

Die Kommunikation zwischen dem Authorization Server des Fachdienstes in seiner Rolle als OpenID-Relying-Party der TI-Föderation und dem sektoralen Identity Provider (OpenID Provider) entspricht den Spezifikationen [OpenID Connect Core 1.0] sowie Pushed Authorization Requests (PAR) gemäß [RFC 9126]. Auch diese Kommunikationsbeziehungen werden im vorliegenden Dokument nicht detailliert betrachtet.

Abbildung 6 : Komponenten der TI-Föderation mit Schnittstellen 

Erläuterungen zur obigen Abbildung:

Die jeweiligen Teilnehmertypen (entity_type) sind farblich unterschiedlich dargestellt.

Die Fachdienste (gelb) bestehen in der Regel aus mehreren Komponenten. Die Authorization Server der Fachdienste autorisieren den Fachdienst-Client nach erfolgreicher Prüfung der Zugriffsberechtigungen zum Zugriff auf die Daten und Geschäftsprozesse der Fachdienste (Resource Server). In der TI-Föderation erfolgt diese Prüfung auf Grundlage einer vorherigen Authentifizierung des Nutzers bei einem Identity Provider. Die Nutzer, die über einen Fachdienst-Client auf einen Fachdienst zugreifen möchten, müssen sich hierzu bei einem Identity Provider authentifizieren. Die sektoralen Identity Provider (blau) verwalten die Identitätsinformationen der Nutzer und führen den Authentifizierungsprozess durch. Erst nach erfolgreicher Nutzerauthentifizierung stellt der Authorization Server eines Fachdienstes dem Fachdienst-Client eine entsprechende Zugriffsberechtigung aus.

Im Kontext der TI-Föderation sind die Authorization Server der Fachdienste als OpenID-Relying-Parties (entity_type = openid_relying_party) und die sektoralen Identity Provider als OpenID Provider (entity_type = openid_provider) registriert.

Die Fachdienst-Clients sind nicht Teil der TI-Föderation.

Die Resource Server der Fachdienste können ebenfalls im Vertrauensraum der TI-Föderation als oauth_resource registriert werden. Anwendungen können den Vertrauensraum der TI-Föderation nutzen, um die Vertrauenswürdigkeit eines Fachdienstes als Kommunikationspartner nachzuweisen. So kann beispielsweise die Registrierung des PoPP-Service in der TI-Föderation für Anwendungen hilfreich sein, die ausgestellten PoPP-Token verwenden und diese unabhängig von der Komponenten-PKI der gematik prüfen wollen. Die PoPP-Token werden vom PoPP-Service signiert. Der zugehörige öffentliche Schlüssel ist im Entity Statement des PoPP-Service hinterlegt. Über die TI-Föderation wird sichergestellt, dass nutzende Anwendungen dem Entity Statement und damit auch der Signatur der PoPP-Token vertrauen können. 

Der Federation Master (grün) umfasst Komponenten des Typs federation_entity mit Funktionen zur Prüfung der Vertrauenskette eines Teilnehmers bis zum Vertrauensanker. Darüber hinaus stellt er Funktionen zur Bereitstellung von Informationen über Teilnehmer der TI-Föderation sowie zur Abbildung von Regeln (Policies) und Vertrauensnachweisen (Trust Marks) bereit.

Die Schnittstellen zwischen den Komponenten der TI-Föderation sind durch durchgezogene Linien dargestellt. Die gestrichelten Linien visualisieren hingegen organisatorische Prozesse und Verfahren mit Komponenten außerhalb der TI-Föderation. Die Schnittstellen zwischen der Registrierungs-Engine und dem Federation Master sind jedoch Bestandteil der technischen Schnittstellenspezifikation.

Innerhalb des Vertrauensraums der TI-Föderation müssen die beteiligten Teilnehmer sicherstellen, dass ihr jeweiliger Kommunikationspartner ebenfalls Mitglied der TI-Föderation ist. Hierzu stellt jeder Teilnehmer ein selbst signiertes Entity Statement bereit. Zur Herstellung einer Vertrauensbeziehung ruft ein Teilnehmer das Entity Statement seines Kommunikationspartners über dessen öffentlich erreichbare /.well-known/openid-federation Schnittstelle ab.

Zusätzlich ruft der anfragende Teilnehmer von der Superior Entity (Federation Master oder Intermediate), der der Kommunikationspartner direkt untergeordnet ist, ein Subordinate Statement ab. Dieses enthält Informationen über die Eigenschaften des Kommunikationspartners innerhalb der TI-Föderation.

Die Vertrauenswürdigkeit prüfen die Kommunikationsteilnehmers durch die Validierung der Trust Chain vom Entity Statement des Teilnehmers bis zum Trust Anchor der TI-Föderation (Federation Master).

4.3 Akteure und Rollen

Im Systemkontext der TI-Föderation interagieren verschiedene Akteure (Nutzer und aktive Komponenten) in unterschiedlichen OAuth2-Rollen gemäß [RFC6749#section-1.1] und OpenID-Connect-Rollen gemäß [OpenID Connect Core 1.0] und [OpenID Federation 1.1].

Als sektoraler IDP wird ein Dienst bezeichnet, welcher die Nutzerauthentifizierung durchführt. Nach erfolgreicher Nutzerauthentisierung stellt der sektorale IDP Identitätsinformationen zum Nutzer bereit. Die Identitätsinformationen werden von den Fachdiensten zur Durchführung einer Nutzerautorisierung verwendet, also zur Feststellung, auf welche Fachdaten und -prozesse des Fachdienstes dem Nutzer Zugriff gewährt wird. Die bereitgestellten Identitätsinformationen sind spezifisch für die unterschiedlichen Gruppen von Nutzern bzw. Sektoren innerhalb der TI des Gesundheitswesens. Einen Sektor stellen insbesondere die Krankenversicherungen mit den Versicherten als Nutzer dar. Es können allerdings auch andere Personengruppen wie z. B. Ärzte oder Pflegeinstitutionen über sektorale IDP angebunden werden.

Die Abläufe zur Nutzerauthentifizierung für einen Fachdienst sowie der Herausgabe der Identitätsinformationen durch den sektoralen IDP sind als der innere und der äußere Flow im Kapitel "Interaktionen" erläutert.

Tabelle 3 : Akteure und Rollen

Nutzer (Rolle: Resource Owner) 

Der Resource Owner ist eine natürliche Person, die auf die vom Fachdienst (Resource Server) bereitgestellten geschützten Ressourcen (Protected Resources) zugreift.

Dem Resource Owner sind folgende Komponenten zugeordnet:

• Endgerät des Nutzers,
• App mit Authenticator-Modul des sektoralen Identity Providers auf dem Endgerät,
• Anwendungsfrontend des Fachdienstes (Web-Anwendung oder App) auf dem gleichen oder einem anderen Endgerät.

Fachdienst (Rolle: Authorization Server)

Der Authorization Server des Fachdienstes verarbeitet die vom Anwendungsfrontend eingehenden Authorization Requests. Nach erfolgreicher Authentifizierung des Nutzers durch einen OpenID Provider stellt er dem Anwendungsfrontend ein Access Token sowie optional ein Refresh Token aus.

Fachdienst (Rolle: OpenID-Relying-Party)

Der Fachdienst initiiert in seiner Rolle als OpenID-Relying-Party die Authentifizierung des Nutzers beim sektoralen Identity Provider. Nach erfolgreicher Authentifizierung erhält er einen Authorization Code und tauscht diesen beim Identity Provider gegen ein ID-Token und ein Access-Token aus. Die im ID-Token enthaltenen Informationen nutzt der Fachdienst in der Rolle OpenID-Relying-Party anschließend zur Durchführung fachlicher Autorisierungsentscheidungen. Auf Grundlage dieser Entscheidungen stellt der Fachdienstes in seine Rolle als Authorization Server dem Anwendungsfrontend ein Access-Token und gegebenenfalls ein Refresh-Token für den Zugriff auf die geschützten Ressourcen des Fachdienstes aus.

Fachdienst (Rolle: Resource Server)

Der Fachdienst stellt in seiner Rolle als Resource Server die geschützten Ressourcen (Protected Resources) bereit. Er prüft die vom Client vorgelegten Access-Tokens und gewährt auf dieser Grundlage den Zugriff auf die angeforderten Fachdaten und Fachprozesse. Das Access-Token repräsentiert dabei die dem Client erteilte Berechtigung, im Auftrag des Resource Owners auf die geschützten Ressourcen zuzugreifen.

Anwendungsfrontend (Rolle: OAuth-Client)

Das Anwendungsfrontend übernimmt die Rolle des OAuth Clients. Es greift auf die von Fachdiensten bereitgestellten geschützten Ressourcen (Protected Resources) zu. Die Ausführung kann als Web-Anwendung, Desktop-Anwendung oder mobile Anwendung erfolgen.

Befinden sich Teile der Anwendungslogik in einem Hintergrundsystem, sind die zur Bereitstellung der Benutzeroberfläche erforderlichen Backend-Komponenten ebenfalls Bestandteil des Clients.

Sektoraler IDP mit dem Authenticator-Modul als Frontend (Rolle: OpenID Provider)

Der sektorale Identity Provider (IDP) ist im eigentlichen Sinne auch ein Authorization Servers, übernimmt aber im Rahmen von OpenID Connect die Rolle eines OpenID Providers. Er authentifiziert den Nutzer (Resource Owner) und stellt nach erfolgreicher Authentifizierung einen Authorization Code aus.

Dieser Authorization Code kann von der OpenID-Relying-Party beim sektoralen Identity Provider gegen ein ID-Token eingetauscht werden. Das ID-Token enthält Informationen über den Nutzer in Form von Claims. Diese Informationen werden vom Fachdienst genutzt, um Autorisierungsentscheidungen zu treffen und festzustellen, auf welche Fachdaten und Fachprozesse dem Nutzer Zugriff gewährt werden darf.

Die im ID-Token enthaltenen Informationen richten sich nach den vom Fachdienst angeforderten Scopes und den hierfür bereitgestellten Claims.

Attributbestätigende Stelle

Attributbestätigende Stellen sind legitimierte Organisationen, die für die Richtigkeit der von ihnen bestätigten Nutzerattribute verantwortlich sind. Sie stellen dem sektoralen Identity Provider (IDP) verlässliche Informationen über einen Nutzer zur Verfügung und bestätigen deren Gültigkeit.

Im Rahmen der Einrichtung der GesundheitsID ist eine eindeutige und verlässliche Identifizierung des Nutzers zwingend erforderlich. Hierfür werden eindeutige Identifikationsmerkmale der realen Identität erfasst und dem sektoralen Identity Provider als Identitätsinformationen bereitgestellt.

Die eindeutigen Identitäten natürlicher Personen (z. B. Versicherte und Leistungserbringer) sowie juristischer Personen (z. B. medizinische Einrichtungen, Organisationen des Gesundheitswesens, Gesellschafterorganisationen der gematik und Krankenkassen als Kostenträger) werden innerhalb der Telematikinfrastruktur über entsprechende Identifikatoren repräsentiert. Für Versicherte wird hierzu insbesondere die Krankenversichertennummer (KVNR) verwendet. Leistungserbringer, medizinische Institutionen und weitere Organisationen des Gesundheitswesens werden über ihre Telematik-ID identifiziert.

Federation Master (Rolle: Trust Anchor, Superior)

Der Federation Master ist eine zentrale Komponente der TI-Föderation und ein eigenständiger Produkttyp gemäß [gemSpec_IDP_FedMaster]. Er stellt unter anderem die folgenden Anwendungsfälle bereit:

• Teilnehmer registrieren, deregistrieren und Teilnehmerdaten ändern,
• Liste der direkt registrierten Teilnehmer bereitstellen,
• Liste der registrierten sektoralen Identity Provider (IDP-Liste) bereitstellen,
• Entity Statements bereitstellen,
• Subordinate Statements für direkt registrierte Teilnehmer bereitstellen,
• Trust Marks für direkt registrierte Teilnehmer bereitstellen,
• Schlüssel von TLS-Zertifikaten abgleichen,
• Schlüssel direkt registrierter Teilnehmer verwalten.

Alle Teilnehmer der TI-Föderation müssen bei einer Superior Entity registriert sein. Teilnehmer der Föderation sind in diesem Kontext insbesondere alle Fachdienste in ihrer Rolle als OpenID-Relying-Parties (in der Regel die Authorization Server der Fachdienste) sowie die sektoralen Identity Provider.

Die Registrierung erfolgt über die Prozesse der Registrierungs-Engine und die hierfür bereitgestellten Schnittstellen des Federation Masters*. Der Federation Master verwaltet die öffentlichen Schlüssel aller direkt registrierten Teilnehmer. Für direkt registrierte Fachdienste in ihrer Rolle als OpenID-Relying-Party verwaltet er zusätzlich die jeweils zulässigen Scopes, Claims und redirect_uris.

Darüber hinaus stellt der Federation Master auf Anfrage Teilnehmerbestätigungen in Form von Subordinate Statements für die bei ihm direkt registrierten Teilnehmer der TI-Föderation aus.

Im Sinne der Spezifikation [OpenID Federation 1.1] ist der Federation Master der Trust Anchor der TI-Föderation. D.h., er ist bei keiner weiteren Superior Entity registriert und bildet somit den Endpunkt der Vertrauenskette (Trust Chain) gemäß [OpenID Federation 1.1]. Die Vertrauenskette aller Teilnehmer der TI-Föderation muss auf den Federation Master zurückführbar sein ("Trust Chain").

Zusätzlich stellt der Federation Master eine Schnittstelle bereit, über die eine Liste aller in der TI-Föderation registrierten sektoralen Identity Provider abgerufen werden kann.

* Bis zur Produktivsetzung der Registrierungs-Engine erfolgt die Registrierung von Teilnehmern über einen organisatorischen Prozess, der durch den Anbieter des Produkttyps Federation Master bereitgestellt wird.

Intermediate (Rolle: Superior)

Die Eigenschaften eines Intermediate der TI-Föderation sind ebenfalls im Produkttyp [gemSpec_IDP_FedMaster] definiert. Ein Intermediate bildet den Knotenpunkt einer Teilstruktur der TI-Föderation und ist – wie der Federation Master – vom Typ Federation Entity.

Teilnehmer mit gemeinsamen technischen oder organisatorischen Eigenschaften können bei einem entsprechenden Intermediate registriert werden. Ein Intermediate ist selbst Teilnehmer der TI-Föderation und muss daher ebenfalls bei einem anderen Intermediate oder direkt beim Federation Master registriert sein. Die Registrierung erfolgt technisch innerhalb des Produkttyps „Federation Master“.

Wie der Federation Master verwaltet ein Intermediate die öffentlichen Schlüssel aller direkt bei ihm registrierten Teilnehmer. Zusätzlich verwaltet es für die als OpenID-Relying-Parties registrierten Fachdienste die jeweils zulässigen Scopes, Claims und redirect_uris. Darüber hinaus stellt es auf Anfrage Teilnehmerbestätigungen in Form von Subordinate Statements für die bei ihm direkt registrierten Teilnehmer der TI-Föderation aus.

Intermediates der TI-Föderation unterstützen insbesondere die folgenden Anwendungsfälle:

• Teilnehmer registrieren, deregistrieren und Teilnehmerdaten ändern,
• Liste der direkt registrierten Teilnehmer bereitstellen,
• Entity Statements bereitstellen,
• Subordinate Statements für direkt registrierte Teilnehmer bereitstellen,
• Trust Marks für direkt registrierte Teilnehmer bereitstellen,
• Schlüssel direkt registrierter Teilnehmer verwalten.

Registrierungskomponente:

Die Registrierungskomponente übernimmt die Aufgabe, Registrierungsanträge von Teilnehmern der TI-Föderation entgegenzunehmen, zu validieren und mit anderen Systemen zu synchronisieren. Hierzu verfügt sie über Schnittstellen zur TI-Föderation, zum Data Warehouse (DWH) der gematik, zum TI-ITSM der gematik sowie zum gematik-myServices-Portal.

Die TI-Föderation stellt Schnittstellen bereit, über die die Registrierungskomponente Teilnehmerkonfigurationen (Entity Configurations) prüfen kann. Darüber hinaus werden Schnittstellen für die Neuregistrierung, die Änderung bestehender Registrierungen sowie die Deregistrierung von Teilnehmern der TI-Föderation bereitgestellt.

Die Registrierungskomponente übermittelt die Teilnehmerdaten der TI-Föderation an das Data Warehouse (DWH) der gematik. Diese Daten dienen Zwecken des Business Intelligence (BI), der Berichterstellung sowie der Durchführung von Analysen zur Unterstützung der Betriebsführung der gematik.

Nach erfolgreicher Prüfung eines Teilnehmerantrags erfolgt die Aktualisierung des Vertrauensraums der TI-Föderation über die entsprechenden Schnittstellen des Federation Masters.

4.4 Schnittstellen

Tabelle 4 : Schnittstellen zwischen den Teilnehmern und Komponenten der TI-Föderation

4.5 Schlüsselmanagement

Im Ablauf der Nutzerauthentifizierung innerhalb der TI-Föderation werden zwischen den beteiligten Komponenten unterschiedliche kryptographische Verfahren und Schlüssel zur Sicherstellung von Vertraulichkeit, Integrität und Authentizität der Kommunikation verwendet.

Abbildung 7 : Schlüsselmanagement für die Nutzerauthentifizierung in der TI-Föderation

Tabelle 5 : Schlüsselmanagement

Teilnehmer können zusätzlich zu den verpflichtenden Schlüsseln weitere kryptographische Schlüssel in ihren Metadatenblöcken veröffentlichen. Auch für den Schlüsselwechsel (Key Rollover) werden die im OpenID Federation-Standard definierten Mechanismen genutzt. Hierzu werden die Claims "jwks" im Common Block des Entity Statements für den Federation Entity Signing Key sowie "jwks" beziehungsweise "signed_jwks_uri" in den jeweiligen Metadatenblöcken des Entity Statements für alle weiteren Schlüssel verwendet.

5 Abläufe & Interaktionen

5.1 Kurzbeschreibung

Der Authentifizierungsprozess basiert aus Gründen der Entkopplung zwischen den Authentifizierungsmethoden und Token-Formaten der sektoralen Identity Provider (IDP) und der Fachdienste auf zwei ineinandergeschachtelten Abläufen.
Zum einen existiert der äußere Flow zwischen dem Anwendungsfrontend und dem Fachdienst in seiner Rolle als Authorization Server. Dieser Ablauf ist anwendungsspezifisch, sollte jedoch als OAuth-2.0-Authorization-Code-Flow umgesetzt werden.
Zum anderen existiert der innere Flow zwischen den Teilnehmern der TI-Föderation. Dieser basiert auf OpenID Connect (OIDC) und ist als OAuth-2.0-Authorization-Code-Flow realisiert.
Im äußeren Flow wendet sich das Anwendungsfrontend als Client zunächst an den Authorization Server des Fachdienstes und signalisiert diesem über einen zusätzlichen Parameter – im Folgenden als idp_iss bezeichnet – den für die Authentifizierung zu verwendenden sektoralen Identity Provider.
Der innere Flow beginnt mit einem Pushed Authorization Request (PAR) und endet mit der Bereitstellung eines ID-Tokens durch den sektoralen Identity Provider an den als OpenID-Relying-Party in der TI-Föderation registrierten Fachdienst.
Der Fachdienst tritt im Rahmen des inneren Flows in seiner Rolle als OpenID-Relying-Party als Client gegenüber dem sektoralen Identity Provider auf. Die erste Anfrage wird an den PAR-Endpunkt gemäß [RFC 9126, Abschnitt 2] gesendet. Hierbei übermittelt der Fachdienst einen Pushed Authorization Request zur Authentifizierung des Nutzers sowie zur Bestätigung der angeforderten Scopes und Claims. Zusätzlich wird eine code_challenge gemäß PKCE übermittelt.
Die Scopes und Claims, die ein Fachdienst beim sektoralen Identity Provider anfordern darf, sind im Entity Statement des Fachdienstes hinterlegt und dem sektoralen Identity Provider bekannt.
Im Verlauf des inneren OIDC-Flows wird der Nutzer aufgefordert, sich unter Verwendung des Authenticator-Moduls des sektoralen Identity Providers zu authentifizieren. Die Kommunikation erfolgt dabei über die Schnittstellen zwischen dem Authenticator-Modul und dem Authorization-Endpunkt des sektoralen Identity Providers.
Nach Freigabe des Consent durch den Nutzer sowie erfolgreicher Authentifizierung erstellt der sektorale Identity Provider einen Authorization Code. Dieser wird an den Fachdienst in seiner Rolle als OpenID-Relying-Party übermittelt. Der Fachdienst reicht den Authorization Code anschließend am Token-Endpunkt gemäß [RFC6749] Abschnitt 3.2 ein. Der sektorale Identity Provider validiert den Authorization Code und stellt bei erfolgreicher Prüfung ein ID-Token aus.
Wird der äußere Flow ebenfalls als OAuth-2.0-Authorization-Code-Flow (grant_type=authorization_code) umgesetzt, erzeugt der Fachdienst in seiner Rolle als Authorization Server einen eigenen Authorization Code und übermittelt diesen an das Anwendungsfrontend. Der äußere Flow endet mit der Ausgabe eines Access-Tokens an das Anwendungsfrontend.
Das Anwendungsfrontend verwendet dieses Access-Token für die anwendungsspezifischen Zugriffe auf die geschützten Ressourcen (Protected Resources) des Fachdienstes.
In diesem Kapitel werden die Abläufe für folgende Szenarien beschrieben:

• App2App-Kommunikation,
• Web2App-Kommunikation,
• Kommunikation unter Verwendung von zwei Endgeräten.

Vorbereitende Maßnahmen:

• Die sektoralen Identity Provider haben bei ihrer Registrierung beim Federation Master ihren öffentlichen Federation Entity Signing Key hinterlegt und den öffentlichen Federation Entity Signing Key des Trust Anchors der TI-Föderation (Federation Master) zur Validierung der Trust Chain erhalten.
• Der Fachdienst hat bei seiner Registrierung als OpenID-Relying-Party bei einer Superior Entity (Federation Master oder Intermediate) den öffentlichen Teil seines Federation Entity Signing Key hinterlegt und den öffentlichen Federation Entity Signing Key des Trust Anchors der TI-Föderation zur Validierung der Trust Chain erhalten.
• Der Fachdienst hat bei seiner Registrierung als OpenID-Relying-Party die für die Autorisierungsentscheidung erforderlichen Scopes,  Claims und redirect_uris bei der zuständigen Superior Entity (Federation Master oder Intermediate) hinterlegt.

5.2 App2App-Flow

5.2.1 Vorbedingungen

• Für das Anwendungsfrontend des Fachdienstes ist ein App-Link oder Universal Link auf dem Endgerät des Nutzers registriert, der auf die Redirect-URI des Fachdienstes verweist.
• Für die App mit dem Authenticator-Modul des sektoralen Identity Providers ist ein App-Link oder Universal Link auf dem Endgerät des Nutzers registriert, der auf die entsprechenden Endpunkte des Identity Providers verweist.

5.2.2 Flow - OIDC

5.2.2.1 Flow Diagramm

Abbildung 8 :  Ablauf App2App-Flow

5.2.2.2 Ablaufbeschreibung App2App-Flow

Tabelle 6 : Ablaufbeschreibung App2App-Flow

5.2.2.3 Schnittstellenbeschreibung

(0) Vorbedingung - Abruf Entity Statements des Federation Master

Das selbstsignierte Entity Statement des Federation Masters wird durch einen Teilnehmer der TI-Föderation abgerufen und mithilfe des im Rahmen der Registrierung bekannt gemachten öffentlichen Signaturschlüssels des Federation Masters validiert.

• Request zum Abruf des Entity Statements des Federation Masters

GET /.well-known/openid-federation
Host: app-ref.federationmaster.de 

• Response
• HTTP 200
• Content-Type: application/entity-statement+jwt
• JWT

Die nachfolgende Tabelle zeigt ausgewählte Attribute der Entity Configuration des Federation Masters. Ein ausführliches Beispiel ist im Anhang dokumentiert.

Tabelle 7 : Entity Configuration des Federation Master

(0 a/b) Abfrage der Liste aller in der TI-Föderation registrierten sektoralen IDPs

Die Liste aller in der TI-Föderation registrierten sektoralen Identity Provider (IDP) wird von Anwendungen genutzt, um Nutzern die Auswahl ihrer Krankenversicherung zu ermöglichen. Die Auswahl der zuständigen Krankenversicherung ist erforderlich, da die Authentifizierung mittels GesundheitsID über den sektoralen Identity Provider der jeweiligen Krankenversicherung erfolgt.

• Request zum Abruf in der in der TI-Föderation registrierten sektoralen IDPs über den Federation Masters

GET /federation/listidps

Host: app-ref.federationmaster.de

• Response
• HTTP 200
• Content-Type: application/jwt
• JWT

Die nachfolgende Tabelle beschreibt ausgewählte Attribute der Antwort des Federation Masters zur Liste der in der TI-Föderation registrierten sektoralen Identity Provider.

Tabelle 8 : Liste registrierten sektoralen IDPs

(1) Anfrage vom Anwendungsclient  an den Fachdienst Authorization Server

Das Anwendungsfrontend sendet einen Request an den Fachdienst in seiner Rolle als Authorization Server. Da das Anwendungsfrontend selbst kein Teilnehmer der TI-Föderation ist, liegt die Absicherung des Vertrauensverhältnisses zwischen Anwendungsfrontend und Fachdienst-Authorization Server außerhalb des Vertrauensraums der TI-Föderation.
Die konkrete Ausgestaltung dieser Vertrauensbeziehung obliegt der jeweiligen Anwendung. Hierzu kann beispielsweise ein OAuth-2.0-Authorization-Code-Flow eingesetzt werden, um die Vertrauenswürdigkeit des Kommunikationspartners sicherzustellen.

(1 a/b) Laden der Entity Configuration des sektoralen IDP

Der Fachdienst benötigt in seiner Rolle als in der TI-Föderation registrierte OpenID-Relying-Party die Entity Configuration des sektoralen Identity Providers, um einen Authorization Request erzeugen zu können, der vom sektoralen Identity Provider akzeptiert wird.
Hierzu ruft der Fachdienst das Entity Statement des sektoralen Identity Providers ab und erhält daraus dessen Entity Configuration. 

• Request zum Abruf des Entity Statements des sektoralen Identity Provider

GET /.well-known/openid-federation
Host: gsi-ref.dev.gematik.solutions 

• Response
• HTTP 200
• Content-Type: application/entity-statement+jwt
• JWT

Die nachfolgende Tabelle beschreibt ausgewählte Attribute der Entity Configuration eines sektoralen Identity Providers. Ein vollständiges Beispiel ist im Anhang dokumentiert.

Tabelle 9 : Entity Configuration eines sektoralen IDP

(1 c) Validieren des Entity Statment des sektoralen IDP und Prüfung der Trust Chain

Der Fachdienst in seiner Rolle als OpenID-Relying-Party validiert die vollständige Trust Chain ausgehend vom Entity Statement des sektoralen Identity Providers bis zum Trust Anchor der TI-Föderation.
Hierzu ruft der Fachdienst unter anderem das Subordinate Statement des sektoralen Identity Providers von dessen Superior Entity ab. Im Falle einer direkten Registrierung enthält das vom Federation Master ausgestellte und signierte Subordinate Statement Informationen über den sektoralen Identity Provider als Teilnehmer der TI-Föderation.
Für die Anfrage müssen die ID (iss) der ausstellenden Federation Entity sowie die ID (sub) des Teilnehmers angegeben werden, zu dem die Auskunft eingeholt werden soll.

• Request zum Abruf des Subordinate Statements des Federation Masters zum sektoralen IDP

GET /federation/fetch?iss=https://app-ref.federationmaster.de&sub=https://gsi-ref.dev.gematik.solutions
Host: app-ref.federationmaster.de 

• Response
• HTTP 200
• Content-Type: application/entity-statement+jwt
• JWT

Die nachfolgende Tabelle beschreibt ausgewählte Attribute des Subordinate Statements zum sektoralen Identity Provider. Ein vollständiges Beispiel ist im Anhang dokumentiert.

Tabelle 10 : Subordinate Statement zu einem sektoralen IDP

(2) Der Autorisierungsserver des Fachdienstes sendet ein Pushed Authorization Request

Der innere Flow beginnt mit einem Pushed Authorization Request (PAR) gemäß [RFC9126], den der Fachdienst in seiner Rolle als OpenID-Relying-Party an den pushed_authorization_request_endpoint des sektoralen Identity Providers sendet. Für die Client-Authentifizierung wird das Verfahren self_signed_tls_client_auth gemäß [OpenID Connect Core 1.0] (Abschnitt 9) verwendet

• Pushed Authorization Request

POST /PAR_Auth
Host: gsi-ref.dev.gematik.solutions
Content-Type: application/x-www-form-urlencoded scope=urn%3Atelematik%3Adisplay_name+urn%3Atelematik%3Aversicherter+openid&acr_values=gematik-ehealth-loa-high&response_type=code&state=yyystateyyy&redirect_uri=https%3A%2F%2Fredirect.testsuite.gsi&code_challenge_method=S256&nonce=vy7rM801AQw1or22GhrZ&client_id=https%3A%2F%2Fidpfadi.dev.gematik.solutions&code_challenge=Shfl63eRGqtkndBuvWSFWqnue67tHYSEgQozlntaoJQ

Der Pushed Authorization Request des Fachdienstes an den sektoralen Identity Provider enthält die folgenden Parameter:

Tabelle 11 : Inhalte eines Pushed Authorization Request

(2 a/b) Laden der Entity Configuration des als OpenID-Relying-Party in der TI-Föderation registrierten Fachdienstes

Der sektorale Identity Provider (IDP) benötigt die Entity Configuration des als OpenID-Relying-Party in der TI-Föderation registrierten Fachdienstes, um zu prüfen, ob es sich bei dem anfragenden Fachdienst um einen vertrauenswürdigen Teilnehmer der TI-Föderation handelt und ob der empfangene Authorization Request den Anforderungen der Föderation entspricht.
Hierzu ruft der sektorale Identity Provider das Entity Statement des Fachdienstes in seiner Rolle als OpenID-Relying-Party ab und erhält dadurch dessen Entity Configuration

• Request zum Abruf des Entity Statements eines als OpenID-Relying-Party in der TI-Föderation registrierten Fachdienstes

GET /.well-known/openid-federation
Host: idpfadi.dev.gematik.solutions

• Response

• HTTP 200
• Content-Type: application/entity-statement+jwt
• JWT

Die nachfolgende Tabelle beschreibt ausgewählte Attribute der Entity Configuration eines als OpenID-Relying-Party registrierten Fachdienstes. Ein vollständiges Beispiel ist im Anhang dokumentiert.

Tabelle 12 : Entity Configuration eines Fachdienst als OpenID-Relying-Party

(2 c) Validieren des Entity Statment des Fachdienst als OpenID-Relying-Party und Prüfung der Trust Chain

Der sektorale Identity Provider (IDP) validiert die vollständige Trust Chain ausgehend vom Entity Statement des Fachdienstes in seiner Rolle als OpenID-Relying-Party bis zum Trust Anchor der TI-Föderation.
Hierzu ruft der sektorale Identity Provider unter anderem das Subordinate Statement des Fachdienstes von der Superior Entity ab, bei der der Fachdienst als OpenID-Relying-Party registriert ist. In dem von der Superior Entity ausgestellten und signierten Subordinate Statement werden Informationen über den Fachdienst als Teilnehmer der TI-Föderation bereitgestellt.
Für die Anfrage müssen die ID (iss) der ausstellenden Superior Entity sowie die ID (sub) des Teilnehmers angegeben werden, zu dem die Auskunft angefordert wird.

• Request zum Abruf des Subordinate Statements vom Federation Masters zum Fachdienst

GET /federation/fetch?iss=https://app-test.federationmaster.de&sub=https://idpfadi.dev.gematik.solutions

Host: app-test.federationmaster.de 

• Response mit beispielhaften Werten
• HTTP 200
• Content-Type: application/entity-statement+jwt
• JWT

Die nachfolgende Tabelle beschreibt ausgewählte Attribute des Subordinate Statements zum Fachdienst in seiner Rolle als OpenID-Relying-Party der TI-Föderation. Ein vollständiges Beispiel ist im Anhang dokumentiert.

Tabelle 13 : Subordinate Statement zu einem Fachdienst als OpenID-Relying-Party der TI-Föderation

(3) Anwort des sektoralen IDP auf den Pushed Authorization Request

Der sektorale Identity Provider (IDP) antwortet auf den Pushed Authorization Request des Fachdienstes in seiner Rolle als OpenID-Relying-Party mit einer Request-URI. Die Request-URI ist ein für einen einzelnen Authentifizierungsvorgang erzeugter Referenzwert und enthält keine Informationen aus dem ursprünglichen Pushed Authorization Request.
Vor der Erstellung der Antwort verifiziert der sektorale Identity Provider das TLS-Client-Zertifikat des Fachdienstes anhand eines öffentlichen Schlüssels, der im Entity Statement des Fachdienstes veröffentlicht wurde.

• Response mit beispielhaften Werten
• HTTP 201
• Content-Type: application/json
• {
    "request_uri":
      "urn:https://idpfadi.dev.gematik.solutions:2f4c9dc66dcf350e",
      "expires_in": 90
   }

Die nachfolgende Tabelle beschreibt die Attribute der Antwort des sektoralen Identity Providers auf den Pushed Authorization Request.

Tabelle 14 : Request URI, ausgestellt vom sektoralen IDP

Diese URI wird vom Fachdienst (OpenID-Relying-Party) als redirect an das Anwendungsfrontend gesendet um über das Authenticator Modul den sektoralen IDP zu erreichen.

(4) Redirect der Request URI

• HTTP-302
• Location: https://gsi-ref.dev.gematik.solutions/auth?client_id=https://idpfadi.dev.gematik.solutions &
   request_uri=urn:https://idpfadi.dev.gematik.solutions:2f4c9dc66dcf350e
  

Die Tabelle stellt die Attribute im Redirekt zum sektoralen IDP dar.

Tabelle 15 : Inhalte des Redirekt zum sektoralen IDP

(5) Das Anwendungsfrontend sendet den Authentication Request

Das Anwendungsfrontend folgt dem Redirect.

• Request zum Abruf des Authorization Request

GET /auth?request_uri= urn:https://idpfadi.dev.gematik.solutions:2f4c9dc66dcf350e &client_id=https://idpfadi.dev.gematik.solutions

Host: gsi-ref.dev.gematik.solutions

Das Authenticator-Modul des sektoralen Identity Providers fängt diesen Aufruf ab, da die entsprechende URI beziehungsweise der zugehörige App-Link oder Universal Link für die App2App-Kommunikation im Betriebssystem registriert wurde.

(6) Das Authenticator Modul leitet den Authentication Request an den IDP weiter. (proprietär)

Das Authenticator-Modul übermittelt den Authentication Request an den sektoralen Identity Provider.
Die Durchführung der Nutzerauthentifizierung, die Einholung einer gegebenenfalls erforderlichen Consent-Freigabe sowie die Erzeugung des Authorization Codes erfolgen herstellerspezifisch und sind nicht Bestandteil der TI-Föderationsspezifikation.

(7) Der Authorization-Endpunkt des sektoralen IDP antwortet dem Authenticator Modul mit einem Redirect zum Fachdienst. (proprietär)

Nach erfolgreicher Authentifizierung des Nutzers erzeugt der sektorale Identity Provider einen Authorization Code und übergibt diesen über einen Redirect an den Fachdienst in seiner Rolle als OpenID-Relying-Party.

• Response
• HTTP-302
• Location: https://redirect.testsuite.gsi?state=yyystateyyy &
   code=cyd6LM-GUE2y0ce313g-A3NVE4
  

Die nachfolgende Tabelle beschreibt die Attribute des Redirects an den Fachdienst in seiner Rolle als OpenID-Relying-Party.

Tabelle 16 : Inhalte des Redirekt zum Fachdienst als OpenID-Relying-Party

(8) Das Authenticator Modul sendet den Request

• Request zum Aufruf des Fachdienst (OpenID-Relying-Party) vom Authenticator Modul des sektoralen IDP

GET ?state=yyystateyyy&code=cyd6LM-GUE2y0ce313g-A3NVE4

Host: redirect.testsuite.gsi 

Das Anwendungsfrontend fängt diesen Request dadurch das er diese Adresse für App2App Kommunikation im Betriebssystem registriert hat.

(9) Aufruf des Fachdienst (OOpenID-Relying-Party) 

Das Anwendungsfrontend ruft den Fachdienst (OpenID-Relying-Party) auf und sendet als Parameter den vom sektoralen IDP ausgestellten Authorization Code sowie den state-Parameter.

• Request zum Aufruf des Fachdienst (OpenID-Relying-Party) vom Anwendungsfrontend des Fachdienstes

POST state=yyystateyyy&code=cyd6LM-GUE2y0ce313g-A3NVE4

Host: redirect.testsuite.gsi

state=yyystateyyy&code=cyd6LM-GUE2y0ce313g-A3NVE4

(10) Abruf des ID-Token

Der Fachdienst reicht den Authorization Code als OpenID-Relying-Party beim Token-Endpunkt des sektoralen IDP ein. 

• Request zum Abruf des ID-Token beim sektoralen IDP durch den Fachdienst als OpenID-Relying-Party

POST /token 

Host: gsi-ref-mtls.dev.gematik.solutions

grant_type=authorization_code&code=cyd6LM-GUE2y0ce313g-A3NVE4?code_verifier=e8ctQxmrak13OHv8dAlQyBKlrN2E6F-Bx3h48RaRX3lJURyD6Be1ehfNpiiJwz9zGehVW0DjoW87JZfwZooAjg-jeA858qWr_Fd7EnK-xxkVc8zdomFJJTcjt9xIQdC4&client_id=https://idpfadi.dev.gematik.solutions&redirect_uri=https://redirect.testsuite.gsi

Die Tabelle stellt die Attribute für den Abruf des ID-Token vom sektoralen IDPs durch den Fachdienst als OpenID-Relying-Party dar.

Tabelle 17 : Attribute für den Abruf des ID-Token vom sektoralen IDP

(11) Ausstellung des ID_TOKEN

Der Fachdienst als OpenID-Relying-Party erhält vom Token-Endpunkt des sektoralen IDP einen ID-Token mit den gewünschten Claims. Das ID-Token ist mit einem Verschlüsselungsschlüssel des Fachdienstes verschlüsselt. Der sektorale IDP verwendet für die Verschlüsselung einen Encryption Key aus dem Metadatenblock im Entity Statement des als OpenID-Relying-Party in der TI-Föderation registrierten Fachdienstes. Der sektorale IDP signiert das ID-Token mit einem Signaturschlüssel dessen öffentlicher Teil im  Metadatenblock seines Entity Statements veröffentlicht ist.

• Response
• HTTP-200
• Content-Type=application/json
• Cache-Control=no-store
• Pragma=no-cache
• JSON

{

"id_token": "eyJhbGciOiJSUzI1NiIsIm.ewogImlzc
    yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
    NzYxMDAxIiwKICJ...",

"token_type": "Bearer",

"expires_in": 300

}

• Encryption Header des JWS

{
  "use": "enc",
  "kid": "puk_fd_enc",
  "alg": "ES256"
}

• Signatur Header des JWS

{
  "use": "sig",
  "kid": "puk_fed_idp_token",
  "alg": "ES256"
}

• Payload

Die Tabelle stellt die Attribute des ID-Token dar.

Tabelle 18 : Attribute des ID-Token

(12) Authorization Code für das Anwendungsfrontend

Sofern die Kommunikation zwischen Anwendungsfrontend, Authorization Server und den geschützten Ressourcen des Fachdienstes ebenfalls mittels OAuth 2.0 erfolgt, erzeugt der Fachdienst in seiner Rolle als Authorization Server einen eigenen Authorization Code (AUTHORIZATION_CODE_AS). Dieser wird an das Anwendungsfrontend zurückgegeben und anschließend vom Anwendungsfrontend am Token-Endpunkt des Fachdienstes eingereicht.

• Response
• HTTP-200
• Content-Type: application/json
  {
    "code":"
      "eaf8NQ-IWG4a2eg535i-C5PXG6",
      "state": "state_frontend"
   }
  

Die nachfolgende Tabelle beschreibt die Attribute der Antwort des Authorization Servers des Fachdienstes.

Tabelle 19 : Response vom Fachdienst Authorization Server an den Fachdienst-Client (Authorization-Code-Flow)

(13)Abruf des Access-Token

Das Anwendungsfrontend des Fachdienstes reicht den vom Authorization Server des Fachdienstes ausgestellten Authorization Code am Token-Endpunkt ein, um ein Access-Token und gegebenenfalls ein Refresh-Token zu erhalten.

• Request zum Abruf des Access-Token beim Fachdienst Authorization Server durch das Anwendungsfrontend des Fachdienstes

POST /token

Host: idpfadi.dev.gematik.solutions

Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=eaf8NQ-IWG4a2eg535i-C5PXG6
&code_verifier=cwYI3ZkRp0JXArqKPxKJGB7QK ....
&client_id=xyz_fachdienst_frontend_id

Die nachfolgende Tabelle beschreibt die Parameter für den Abruf des Access-Tokens am Token-Endpunkt des Authorization Servers des Fachdienstes.

Tabelle 20 : Abruf des Access-Token am Fachdienst Authorization Server

(14) Ausgabe des Access-Tokenauf Fachdienst

Das Anwendungsfrontend erhält vom Authorization Server des Fachdienstes ein Access-Token. Zusätzlich kann der Authorization Server ein Refresh-Token ausstellen, mit dem nach Ablauf des Access-Tokens ein neues Access-Token angefordert werden kann.

• Response

• HTTP-200
• Content-Type=application/json
• Cache-Control=no-store
• Pragma=no-cache

• JSON

{

"access_token" : "f72f1if22ceh919ce621f7012hee98881d949g85",
"token_type" : "Bearer",
"expires_in" : 12000,
"refresh_token" : "VXxl4axvYNPR8DxI8WE7WMJZA4Ga8gGq02HUAcz8Ax0"

}

(15) Verwendung des Access-Token

Greift das Anwendungsfrontend auf eine geschützte Ressource des Fachdienstes zu, wird das Access-Token bei jedem Request übermittelt. Der Resource Server des Fachdienstes validiert das Access-Token und entscheidet auf dieser Grundlage über die Autorisierung des Zugriffs.

• Request
• POST /resource HTTP/1.1
  Authorization: Bearer f72f1if22ceh919ce621f7012hee98881d949g85
  Host: idpfadi.dev.gematik.solutions
  

5.3 Web2App-Flow

Der konkrete OAuth-2.0-Flow ist von der jeweiligen Anwendungsarchitektur abhängig. Die Spezifikation [OAuth 2.0 for Browser-Based Applications] unterscheidet verschiedene Architekturansätze, die unterschiedliche Auswirkungen auf die Ausgestaltung des OAuth-2.0-Flows sowie die damit verbundenen Sicherheitsanforderungen haben.

• Die Architekturvarianten gemäß [OAuth 2.0 for Browser-Based Applications], Abschnitt 6.1 (Backend for Frontend, BFF), und Abschnitt 6.2 (Token-Mediating Backend) werden im Rahmen der vorliegenden Spezifikation nicht gesondert betrachtet, da sich die wesentlichen Abläufe im Kontext der TI-Föderation nicht unterscheiden. 
• Der in Abschnitt 6.3 beschriebene Fall einer reinen Browseranwendung, bei der das Anwendungsfrontend ausschließlich im Browser ausgeführt wird und keine Backend-Komponente vorhanden ist, wird für Anwendungen des Gesundheitswesens mit Anforderungen an eine sichere Nutzerauthentifizierung nicht als relevanter Anwendungsfall betrachtet.

Für Web-Anwendungen sollten die in in [OAuth 2.0 Security Best Current Practice] beschriebenen Sicherheitsanforderungen und Empfehlungen berücksichtigt werden.
Der Ablauf des OIDC-Flows entspricht grundsätzlich dem zuvor beschriebenen App2App-Flow. Unterschiede ergeben sich lediglich in der Kommunikation zwischen Anwendungsfrontend und Authenticator-Modul sowie in der technischen Umsetzung der Weiterleitungen.

5.3.1 Vorbedingungen

• Für die App mit dem Authenticator-Modul des sektoralen Identity Providers ist auf dem Endgerät des Nutzers ein App-Link beziehungsweise Universal Link registriert, der auf die Endpunkte des sektoralen Identity Providers verweist.
• Der Fachdienst verfügt über eine Backend-Komponente, welche die fachliche Anwendungslogik bereitstellt und die Kommunikation mit den Komponenten der TI-Föderation übernimmt.
  

5.3.2 Flow - OIDC

5.3.2.1 Flow Diagramm

Abbildung 9 : Ablauf Web2App-Flow

5.3.2.2 Ablaufbeschreibung Web2App-Flow

Tabelle 21 : Ablaufbeschreibung Web2App-Flow

Schnittstellendetails analog App2App Flow (10)   Web2App Flow

5.4 2-Geräte-Flow

Der 2-Geräte-Flow beschreibt den Anwendungsfall, bei dem das Anwendungsfrontend des Fachdienstes und das Authenticator-Modul des sektoralen Identity Providers auf unterschiedlichen Endgeräten ausgeführt werden. Ein typisches Szenario ist die Nutzung einer Anwendung im Browser eines PCs, während die Authentifizierung über die App des sektoralen Identity Providers auf einem Smartphone erfolgt.
Der Ablauf basiert fachlich auf dem gleichen OIDC-Flow wie der App2App-Flow. Die Übergabe der Authentifizierungsanfrage an das Authenticator-Modul erfolgt jedoch geräteübergreifend. Hierzu können beispielsweise QR-Codes, numerische Codes oder andere vom sektoralen Identity Provider bereitgestellte Verfahren zur Gerätekopplung eingesetzt werden.

5.4.1 Vorbedingungen

• Für die App mit dem Authenticator-Modul des sektoralen Identity Providers ist auf dem mobilen Endgerät des Nutzers ein App-Link beziehungsweise Universal Link registriert, der auf die Endpunkte des sektoralen Identity Providers verweist.
• Der Fachdienst verfügt über eine Backend-Komponente, welche die fachliche Anwendungslogik bereitstellt und die Kommunikation mit den Komponenten der TI-Föderation übernimmt.
• Das Authenticator-Modul des sektoralen Identity Providers läuft auf einem anderen Endgerät als das Anwendungsfrontend des Fachdienstes. Ein typisches Beispiel ist die Nutzung des Authenticator-Moduls auf einem Smartphone bei gleichzeitiger Nutzung der Anwendung über einen Webbrowser auf einem PC oder Notebook

5.4.2 Flow - OIDC

5.4.2.1 Flow Diagramm

Abbildung 10 : Ablauf 2-Geräte-Flow

5.4.2.2 Ablaufbeschreibung 2-Geräte-Flow

Tabelle 22 : Ablaufbeschreibung 2-Geräte-Flow

5.5 Flow Desktop-Anwendung mit integriertem Authenticator-Modul

Für Anwendungen, die auf einem Desktop-PC ausgeführt werden, kann neben dem 2-Geräte-Flow auch eine direkte Authentifizierung innerhalb der Desktop-Anwendung erfolgen, sofern diese ein Authenticator-Modul integriert. Diese Ausprägung ist derzeit für das ePA-Desktop-FdV umgesetzt.
Die Authenticator-Module der ePA-Desktop-FdV-Anwendungen stehen für die gängigen Desktop-Betriebssysteme zur Verfügung. Die Authentifizierung erfolgt dabei über einen angeschlossenen Kartenleser unter Verwendung der elektronischen Gesundheitskarte (eGK) und der zugehörigen PIN.
Der Ablauf entspricht grundsätzlich dem in Kapitel „App2App-Flow“ beschriebenen OIDC-Flow. Der wesentliche Unterschied besteht darin, dass die Funktionen des Authenticator-Moduls direkt innerhalb der Desktop-Anwendung bereitgestellt werden und somit kein separates mobiles Endgerät erforderlich ist.

5.5.1 Vorbedingungen

• Das Authenticator-Modul ist Bestandteil der Desktop-Anwendung.
• Es ist ein kompatibles Kartenlesegerät an den Desktop-PC angeschlossen.
• Dem Nutzer steht  eGK mit PIN als Authentifizierungsmedium zur Verfügung.

5.5.2 Flow - OIDC

5.5.2.1 Flow Diagramm

Abbildung 11 : Ablauf Desktop-App-Flow

5.5.2.2 Ablaufbeschreibung Desktop-App-Flow

Tabelle 23 : Ablaufbeschreibung Desktop-App-Flow

5.6 Unterstützung Single-Sign-On auf Anwendungsebene

Ein Single-Sign-On (SSO) auf Anwendungsebene ermöglicht es einem Nutzer, sich innerhalb einer Anwendung nur einmal aktiv zu authentifizieren und anschließend auf mehrere TI-Fachdienste zuzugreifen, ohne für jeden Fachdienst erneut eine aktive Authentifizierung durchführen zu müssen.
Grundsätzlich erfordert jeder Zugriff auf einen TI-Fachdienst eine aktive Authentifizierung des Nutzers. Unter bestimmten Voraussetzungen kann jedoch auf Anwendungsebene ein SSO-Verfahren eingesetzt werden:

• Die Anwendung ist ein von der gematik zugelassenes Frontend des Versicherten (FdV), beispielsweise das ePA-FdV. 
• Der Nutzer hat der Nutzung von SSO für den jeweiligen TI-Fachdienst ausdrücklich zugestimmt.

Die nachfolgende Matrix zeigt beispielhaft die Nutzung eines Single-Sign-On-Verfahrens innerhalb eines ePA-FdV. In diesem Beispiel kann der Nutzer die TI-Fachdienste E-Rezept, TI-Messenger und Patientenakte sowie eine Funktion seiner Krankenversicherung aus dem ePA-FdV heraus verwenden.
Dabei kann der Nutzer für jeden Fachdienst individuell festlegen, ob eine erneute aktive Authentifizierung erforderlich ist oder eine zuvor durchgeführte Authentifizierung wiederverwendet werden darf. Im dargestellten Beispiel hat der Nutzer die Nutzung von SSO für den Zugriff auf die Patientenakte nicht freigegeben. Beim Öffnen der Patientenakte ist daher eine erneute aktive Authentifizierung erforderlich.
Das Single-Sign-On ist auf die jeweilige Anwendung beschränkt. Eine innerhalb eines ePA-FdV erteilte SSO-Berechtigung gilt nicht automatisch für andere Anwendungen, beispielsweise die E-Rezept-App, eine DiGA-Anwendung oder Anwendungen einer Krankenversicherung.

Abbildung 12 : Beispiel Entscheidungsmatrix für SSO im ePA-FdV

Beim Single-Sign-On (SSO) authentifiziert sich der Nutzer spätestens beim erstmaligen Aufruf eines TI-Fachdienstes innerhalb einer Anwendung gegenüber dem sektoralen Identity Provider (IDP). Anschließend kann der Nutzer für einen definierten Zeitraum weitere TI-Fachdienste sowie anwendungsspezifische Funktionen der Krankenversicherung nutzen, ohne für jeden einzelnen Fachdienst erneut eine aktive Authentifizierung durchführen zu müssen.
Der sektorale Identity Provider stellt dabei sicher, dass für jeden TI-Fachdienst ein eigenes ID-Token ausgestellt wird. Dadurch bleiben die Vertrauensbeziehungen und die Identitätsinformationen der einzelnen Fachdienste voneinander getrennt.
Der Verzicht auf eine aktive Nutzerinteraktion bei jeder Authentifizierung eines TI-Fachdienstes erfordert zusätzliche Sicherheitsmaßnahmen. Diese Maßnahmen müssen sicherstellen, dass die für den jeweiligen Fachdienst geforderte Widerstandsfähigkeit gegenüber dem relevanten Angriffspotenzial weiterhin gewährleistet bleibt.
Eine mögliche spezifikationskonforme Umsetzung besteht in der Verwendung einer vom sektoralen Identity Provider erzeugten Session-ID sowie eines kryptographischen Schlüsselpaars, das sowohl an die Session-ID als auch an die konkrete Instanz des Anwendungskontexts gebunden ist.
Informationen zu den SSO-Präferenzen des Nutzers sowie zur Identität der anfordernden Anwendung werden standardkonform über den Request-Parameter "authorization_details"^[1] übermittelt (siehe [RFC9396 ] sowie [OAuth 2.0 Rich Authorization Requests]).
Ein Single-Sign-On ist derzeit ausschließlich für Fachdienste zulässig, die innerhalb des ePA-FdV eingebunden sind. Die nachfolgende Beschreibung erläutert die Umsetzung daher exemplarisch anhand eines ePA-FdV mit integrierten TI-Fachdiensten.

Abbildung 13 : ePA-FdV mit mehreren integrierten TI-Anwendungen

5.6.1 Prinzipieller Ablauf mit SessionID und Schlüsselpaar

Beim ersten Funktionsaufruf auf einen TI-Fachdienst aus dem ePA-FdV durch den Nutzer 

Beim erstmaligen Aufruf eines TI-Fachdienstes aus dem ePA-FdV durch den Nutzer erfolgen die folgenden Schritte:

• Die im ePA-FdV konfigurierten SSO-Einstellungen des Nutzers für alle an das ePA-FdV angebundenen Fachdienste sowie eine eindeutige Instanz-ID der aufrufenden ePA-FdV-Instanz werden als Request-Parameter in  "authorization_details"^[1]  des Authorization Requests an den Authorization Server übermittelt. 
• Die SSO-Einstellungen des Nutzers sowie die eindeutige Instanz-ID werden ebenfalls als Request-Parameter in "authorization_details"^[1]  des Pushed Authorization Requests an den sektoralen Identity Provider übertragen.
• Der Nutzer authentifiziert sich aktiv über das Authenticator-Modul. Sofern für den betreffenden Fachdienst noch keine Einwilligung des Nutzers vorliegt, wird zusätzlich ein entsprechender Consent-Dialog angezeigt. 
• Die vom sektoralen Identity Provider erzeugte Session-ID wird durch das Authenticator-Modul gespeichert.
• Über Plattformmechanismen wird ein kryptographisches Schlüsselpaar im systemeigenen Schlüsselspeicher erzeugt und an die laufende Instanz des ePA-FdV gebunden.
• Die Session-ID wird vom Authenticator-Modul mit dem privaten Schlüssel des erzeugten Schlüsselpaars signiert.
• Der öffentliche Schlüssel des Schlüsselpaars sowie die signierte Session-ID werden im Rahmen des Authentifizierungsprozesses an den sektoralen Identity Provider übermittelt und dort mit der Nutzeridentität verknüpft.
• Der aufgerufene TI-Fachdienst erhält einen fachdienstspezifischen, einmalig verwendbaren Authorization Code.
• Der als OpenOD Relying Party registrierte TI-Fachdienst erhält ein fachdienst- und nutzerspezifisches ID-Token.
• In einer App2App-Konstellation wird die im Authorization Request (PAR-URI) innerhalb von "authorization_details"^[1]  übermittelte Instanz-ID des ePA-FdV mit der Session-ID verknüpft. Dadurch wird sichergestellt, dass spätere SSO-fähige Authorization Requests derselben ePA-FdV-Instanz zugeordnet werden können.

Weitere Aufrufe von TI-Fachdiensten innerhalb derselben Sitzung
Bei jedem weiteren Aufruf eines TI-Fachdienstes aus derselben Anwendung erfolgen die folgenden Schritte:

• Die eindeutige Instanz-ID der aufrufenden ePA-FdV-Instanz wird als Request-Parameter in "authorization_details"^[1] des Authorization Requests an den Authorization Server übermittelt.
• Die eindeutige Instanz-ID wird ebenfalls wird als Request-Parameter "authorization_details"^[1] im Pushed Authorization Request an den sektoralen Identity Provider übertragen.
• Das Authenticator-Modul prüft anhand der im Authorization Request übermittelten SSO-Parameter, ob der Nutzer der Nutzung von Single Sign-On für den angeforderten Fachdienst zugestimmt hat. 
• Die gespeicherte Session-ID wird aus dem sicheren Speicher geladen.
• Die Session-ID wird erneut mit dem privaten Schlüssel des zugehörigen Schlüsselpaars signiert. 
• Die signierte Session-ID wird im Rahmen des Authorization Requests an den sektoralen Identity Provider übermittelt. 
• Der angeforderte TI-Fachdienst erhält einen neuen fachdienstspezifischen Authorization Code. 
• Der TI-Fachdienst erhält ein neues fachdienst- und nutzerspezifisches ID-Token.
• In einer App2App-Konstellation prüft der sektorale Identity Provider, ob die im Authorization Request übermittelte Instanz-ID des ePA-FdV mit der zur Session-ID gespeicherten Instanz-ID übereinstimmt.

IN-APP- gegenüber APP2APP-Konstellation
Die Varianten IN-APP (Authenticator-Modul ist Bestandteil des ePA-FdV) und APP2APP (Authenticator-Modul als eigenständige Anwendung neben dem ePA-FdV) unterscheiden sich ausschließlich hinsichtlich der technischen Aufrufmechanismen und der Zuordnung zu einer konkreten ePA-FdV-Instanz.
In der APP2APP-Konstellation muss sichergestellt werden, dass Authorization Requests, die eine SSO-Nutzung ermöglichen, tatsächlich von der berechtigten ePA-FdV-Instanz stammen. Hierzu wird die eindeutige Instanz-ID des ePA-FdV im Authorization Request (PAR-URI) als Parameter an das Authenticator-Modul übergeben.
Die Instanz-ID muss:

• als UUID Version 4 [RFC 9562 ] erzeugt werden,
• innerhalb des Anwendungskontexts eindeutig sein,
• bei jedem Start des Anwendungskontexts neu erzeugt werden und
• nach Beendigung des Anwendungskontexts ihre Gültigkeit verlieren.
  Der Anwendungskontext umfasst die Laufzeit einer ePA-FdV-Instanz vom Start bis zur Beendigung der Anwendung durch den Nutzer oder das Betriebssystem. Dadurch wird sichergestellt, dass eine SSO-Sitzung nicht über Anwendungskontexte hinweg wiederverwendet werden kann.

Tabelle 24: Unterschiede im Ablauf IN-APP-Konstellation vs. APP2APP-Konstellation

5.6.2 SSO-Unterstützung auf Anwendungsebene innerhalb einer APP

Das Authenticator-Modul ist in das ePA-FdV integriert.

Abbildung 14: Beispiel für SSO bei Ausführung ePA Client Modul mit aktiver und E-Rezept Client Modul ohne aktive Nutzerauthentisierung aus dem ePA-FdV mit integriertem Authenticator-Modul

5.6.3 SSO-Unterstützung auf Anwendungsebene bei separater Authenticator-APP

Das Authenticator-Modul ist als eigene App implementiert.

Abbildung 15: Beispiel für SSO bei Ausführung ePA Client Modul mit aktiver und E-Rezept Client Modul ohne aktive Nutzerauthentisierung aus dem ePA-FdV mit Authenticator-Modul in separater APP

5.6.4 Ablaufbeschreibung SSO-Flow

Tabelle 25: Ablauf der Aufrufe der TI-Client Module aus dem ePA-FdV 

^[1] Hinweis: Die Anforderungen [A_23208*] aus gemSpec_IDP_Sek sowie [A_23209*] und [A_25047*] aus gemSpec_ePA_FdV fordern jeweils die Einholung einer Nutzerzustimmung zur Nutzung von SSO.
In Abstimmung mit dem BSI ist es nicht erforderlich, diese Zustimmung sowohl über das ePA-FdV als auch über das Authenticator-Modul einzuholen (siehe FAQ-Eintrag „Doppeltes Einholen des SSO-Konsents“ in der IDP-Wissensdatenbank).
In der aktuellen Umsetzung werden die Nutzerpräferenzen zur SSO-Nutzung über das ePA-FdV verwaltet und die entsprechende Nutzerzustimmung dort eingeholt.
Perspektivisch sollen die Nutzerpräferenzen ausschließlich im Authenticator-Modul verwaltet werden. Für die Übergangsphase ist daher die Übermittlung der Nutzerpräferenzen mittels des Parameters "authorization_details" nicht erforderlich.

6 Betriebliche Aspekte

Abbildung 16 : Deploymentview TI-Föderation

6.1 Verfügbarkeiten

6.1.1 Sektorale IDPs

Unabhängig vom Fachdienst ist bei jeder Nutzerauthentifizierung mit GesundheitsID der sektorale IDP involviert. Die Nutzung von TI-Fachdiensten über mobile Endgeräte soll für Versicherte 24x7 möglich sein. Eine Nutzerauthentifizierung mit GesundheitsID muss eine demensprechend hohe Ausfallsicherheit gewährleisten. Daraus ergeben sich folgerichtig Anforderungen an Georedundanz und Wiederherstellungszeiten (siehe auch Kapitel "9 Qualitätsszenarien").

6.1.2 Federation Master

6.1.2.1 TI-Trust Anchor

Der TI-Trust Anchor stellt Schnittstellen zur Abfrage von Subordinate Statements, historical Keys und der Liste der registrierten sektoralen IDP bereit. Diese Abfragen erfolgen bei den Teilnehmern nicht bei jedem Authentisierungsprozess sondern einmal täglich. Die abgefragten Informationen können 24h durch die Teilnehmer gecached werden. Die Anforderungen an die Verfügbarkeit des TI-Trust Anchor können entsprechend dieser Rahmenbedingungen gestaltet werden.

6.1.2.2 Intermediate Entities

Intermediate Entities stellen Schnittstellen zur Abfrage von Subordinate Statements und Trust Marks bereit. Die Anforderungen an die Verfügbarkeit richten sich nach den fachlichen Anwendungsfällen und müssen entsprechend beim Design. der Intermediate Entities berücksichtigt werden.

6.1.3 Fachdienst als OpenID-Relying-Party der TI-Föderation

Anforderungen an Verfügbarkeit von Fachdienst als OpenID-Relying-Party der TI-Föderation richtet sich nach den fachlichen Anwendungsfällen und müssen entsprechend bei Design der Fachdienstes berücksichtigt werden.

6.2 Bearbeitungszeiten

6.2.1 Sektorale IDPs

Das Monitoring der sektoralen Identity Provider umfasst die Verarbeitungszeit innerhalb der sektoralen IDPs aufgrund eingehender Requests. An die unterschiedlichen Requests (Use-Cases) werden betrieblich Anforderungen zur Performance gestellt.

Abbildung 17 : Messpunkte der Bearbeitungsziten sektoraler IDPs

Tabelle 26:  Use-Cases für Bearbeitungszeitvorgaben der sektoralen IDPs

6.2.2 Federation Master

6.2.2.1 TI-Trust Anchor

Das Monitoring des TI-Trust Anchors umfasst die Erfassung und Auswertung der Verarbeitungszeiten für eingehende Requests.
Für die einzelnen Use-Cases werden betriebliche Anforderungen an die Performance des TI-Trust Anchors festgelegt.

Abbildung 18 : Messpunkte der Bearbeitungsziten Trust Anchor

Tabelle 27:  Use-Cases für Bearbeitungszeitvorgaben Federation Master

6.2.2.2 Intermediate Entities

Die Anforderungen an die Performance von Intermediate Entities richten sich nach den fachlichen Anwendungsfällen und sind bei der Konzeption und Implementierung der Intermediate Entities entsprechend zu berücksichtigen.

6.2.3 Fachdienst als OpenID-Relying-Party der TI-Föderation

Die Anforderungen an die Performance von Fachdiensten in ihrer Rolle als OpenID-Relying-Party der TI-Föderation richten sich nach den jeweiligen fachlichen Anwendungsfällen und sind bei der Konzeption und Implementierung der Fachdienste entsprechend zu berücksichtigen.

7 Querschnittsliche Konzepte

Die Anforderungen und Prozesse der TI-Föderation basieren auf den folgenden Konzepten und Spezifikationen der Telematik-Infrastruktur:

• gemSpec_Perf
• gemKPT_Betr
• gemKPT_Test
• gemSpec_DS_Hersteller
• gemSpec_Krypt
• gemSpec_OM
• gemSpec_PKI
• gemSpec_Systemprozesse_dezTI

8 Qualitätsszenarien

Tabelle 28 : Qualitätskriterien

9 Anhang – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

9.3 Abbildungsverzeichnis

9.4 Tabellenverzeichnis

9.5 Referenzierte Dokumente

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

Weitere Referenzierungen:

10 Anhang - Aufbau und Prüfung einer Beispiel-TI-Föderation

10.1 Aufbau der Beispiel TI-Föderation

Anhand der Abbildung „Beispielhafter Aufbau der TI-Föderation“ werden die Entity Configurations und die Validierung von Vertrauensbeziehungen zwischen den Teilnehmern beispielhaft beschrieben.

Hierfür wird angenommen, dass die dargestellte TI-Föderation aus den folgenden Teilnehmern besteht:

Abbildung 19 : Beispiel für den Aufbau einer TI-Föderation

Tabelle 29 : Teilnehmer der beispielhaften TI-Föderation

10.2 Entity Configuration, Entity Statements und Subordinate Statements der Beispiel-TI-Föderation

10.2.1 Beispiel für den common-block (allgemeine Informationen) im Entity Statement jedes Teilnehmers der TI-Föderation

Table # : Attribute des Commonblocks in der Entity Configuration im .well-known-Dokument eines Teilnehmers der TI-Föderation

10.2.2 Beispiel für den Metadatenblock im Entity Statement einer Superior Entity (Trust Anchor, Intermediate) - Federation Master und ZETA-Intermediate

Request zum Abruf Entity Statement des Federation Masters

GET /.well-known/openid-federation
Host: app-ref.federationmaster.de 

Response:

Base64 encoded JWT

eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImtpZCI6InB1a19mZWRtYXN0ZXJfc2lnIiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJodHRwczovL2FwcC1yZWYuZmVkZXJhdGlvbm1hc3Rlci5kZSIsInN1YiI6Imh0dHBzOi8vYXBwLXJlZi5mZWRlcmF0aW9ubWFzdGVyLmRlIiwiaWF0IjoxNzgyMjE4MDYzLCJleHAiOjE3ODIzMDQ0NjMsImp3a3MiOnsia2V5cyI6W3sia3R5IjoiRUMiLCJjcnYiOiJQLTI1NiIsIngiOiJjZElSOGRMYnFhR3J6Zmd5dTM2NUtNNXMwMHpqRnE4REZhVUZxQnZyV0xzIiwieSI6IlhWcDF5U0oya2pFSW5walRaeTB3RDU5YWZFWEVMcGNrMGZrN3ZyTVdyYnciLCJraWQiOiJwdWtfZmVkbWFzdGVyX3NpZyIsInVzZSI6InNpZyIsImFsZyI6Ik...

Decodierter Header

{  "typ": "entity-statement+jwt",
  "kid": "puk_fedmaster_sig",
  "alg": "ES256" }

Decodierte Payload

{ "iss": "https://app-ref.federationmaster.de",
  "sub": "https://app-ref.federationmaster.de",
  "iat": 1782218063,
  "exp": 1782304463,
  "jwks": {
    "keys": [{"kty":"EC","crv":"P-256","x":"cdIR8dLb ...","y":"XVp1ySJ2 ...","kid":"puk_fedmaster_sig","use":"sig","alg":"ES256"}  ]
  },
  "metadata": {
    "federation_entity": {
      "federation_fetch_endpoint": "https://app-ref.federationmaster.de/federation/fetch",
      "federation_list_endpoint": "https://app-ref.federationmaster.de/federation/list",
      "federation_historical_keys_endpoint":"https://app-ref.federationmaster.de/federation/keys",
      "idp_list_endpoint": "https://app-ref.federationmaster.de/federation/listidps",
      "organization_name": "gematik Federation Master",
      "keywords": ["product_type:Federation Master", "product_type_version:2.0.1"],
      "contacts":["support@ti-federation.de"]
    } } }

Tabelle 30: Attribute des Metadatenblocks federation_entity der Entity Configuration im .well-known-Dokument einer Superior Entity (Trust Anchor, Intermediate) der TI-Föderation

10.2.3 Beispiel für den Metadatenblock im Entity Statement eines sektoralen IDP

Request zum Abruf Entity Statement des sektoralen IDP

GET /.well-known/openid-federation
Host: gsi-ref.dev.gematik.solutions

Response:

Base64 encoded JWT

eyJhbGciOiJFUzI1NiIsInR5cCI6ImVudGl0eS1zdGF0ZW1lbnQrand0Iiwia2lkIjoicHVrX2lkcF9zaWcifQ.eyJpc3MiOiJodHRwczovL2dzaS1yZWYuZGV2LmdlbWF0aWsuc29sdXRpb25zIiwic3ViIjoiaHR0cHM6Ly9nc2ktcmVmLmRldi5nZW1hdGlrLnNvbHV0aW9ucyIsImlhdCI6MTc4MjI5NTY1MCwiZXhwIjoxNzgyMzAyODUwLCJqd2tzIjp7ImtleXMiOlt7ImFsZyI6IkVTMjU2IiwiY3J2IjoiUC0yNTYiLCJraWQiOiJwdWtfaWRwX3NpZyIsImt0eSI6IkVDIiwidXNlIjoic2lnIiwieCI6IkFidDJVeXJrNktoY3pleGxCT3dKT1RzX2VCMERzRmJjTnhheGEwWjB2ZDQiLCJ5IjoiWVpLQkp0T1VZRVd.....

Decodierter Header

{ "alg": "ES256",
  "typ": "entity-statement+jwt",
  "kid": "puk_idp_sig" }

Decodierte Payload

{ "iss": "https://gsi-ref.dev.gematik.solutions",
  "sub": "https://gsi-ref.dev.gematik.solutions",
  "iat": 1782300203,
  "exp": 1782307403,
  "jwks": {
    "keys": [{"alg":"ES256", "crv":"P-256","kid":"puk_idp_sig", "kty":"EC", "use":"sig", "x":"Abt2Uyrk ...", "y":"YZKBJtOU ..." } ]
  },
  "authority_hints": ["https://app-ref.federationmaster.de"],
  "metadata": {
    "openid_provider": {
      "issuer": "https://gsi-ref.dev.gematik.solutions",
      "signed_jwks_uri": "https://gsi-ref.dev.gematik.solutions/jws.json",
      "organization_name": "gematik sektoraler IDP",
      "logo_uri": "https://raw.githubusercontent.com/gematik/zero-lab/main/static/images/GID_App_light_mode.png",
      "authorization_endpoint": "https://gsi-ref.dev.gematik.solutions/auth",
      "token_endpoint": "https://gsi-ref-mtls.dev.gematik.solutions/token",
      "pushed_authorization_request_endpoint": "https://gsi-ref-mtls.dev.gematik.solutions/PAR_Auth",
      "client_registration_types_supported": ["automatic"],
      "subject_types_supported": ["pairwise"],
      "response_types_supported": ["code"],
      "scopes_supported": [
        "urn:telematik:geschlecht",
        "urn:telematik:alter",
        "urn:telematik:family_name",
        "urn:telematik:email",
        "openid",
        "urn:telematik:geburtsdatum",
        "urn:telematik:given_name",
        "urn:telematik:versicherter",
        "urn:telematik:display_name"
      ],
      "response_modes_supported": ["query"],
      "grant_types_supported": ["authorization_code"],
      "require_pushed_authorization_requests": true,
      "token_endpoint_auth_methods_supported": ["self_signed_tls_client_auth"],
      "id_token_signing_alg_values_supported": ["ES256"],
      "id_token_encryption_alg_values_supported": ["ECDH-ES"],
      "id_token_encryption_enc_values_supported": ["A256GCM"],
      "user_type_supported": ["IP"],
      "claims_supported": [
        "birthdate",
        "urn:telematik:claims:profession",
        "urn:telematik:claims:family_name",
        "urn:telematik:claims:id",
        "urn:telematik:claims:organization",
        "urn:telematik:claims:email",
        "urn:telematik:claims:geschlecht",
        "urn:telematik:claims:alter",
        "urn:telematik:claims:display_name",
        "urn:telematik:claims:given_name"
      ],
      "claims_parameter_supported": true,
      "ti_features_supported": {
        "id_token_version_supported": [
          "2.0.0",
          "1.0.0"
        ]
      }
      "organization_name": "gematik sektoraler IDP",
      "contacts": [
        "support@idp4711.de",
        "idm@gematik.de"
      ],
      "keywords": ["product_type:Sektoraler IDP", "product_type_version:3.2.0-1"]
    } } }

Decodierte Payload des von der signed_jwks_uri gelesenes JWT

{ "iss": "https://gsi-ref.dev.gematik.solutions",
  "iat": 1782461173,
  "keys": [{ "alg": "ES256", "crv": "P-256", "kid": "puk_fed_idp_token", "kty": "EC", "use": "sig","x": "_knMiY ... ",
      "x5c": ["MIICvzCCAmWgAwIBAgIGPMFPYpg7MAoGCCqGSM49BAMCMIGEMQswCQYDVQQGEwJERTEfMB0GA1UECgwWZ2VtYXRpayBHbWJIIE5PVC1WQUxJRDEyMDAGA1UECwwpS29tcG9uZW50ZW4tQ0EgZGVyIFRlbGVtYXRpa2luZnJhc3RydWt0dXIxIDAeBgNVBAMMF0dFTS5LT01QLUNBNjEgVEVTVC1PTkxZMB4XDTI1MDMwNTAwMDAwMFoXDTMwMDMwNTIzNTk1OVowUDELMAkGA1UEBhMCREUxJjAkBgNVBAoMHWdlbWF0aWsgVEVTVC1PTkxZIC0gTk9ULVZBTElEMRkwFwYDVQQDDBBnc2kgdG9r..." ], "y": "MXTinuJv ..."  } ] }

Tabelle 31 : Attribute des Metadatenblocks openid_provider der Entity Configuration im .well-known-Dokument eines sektoralen IDP in der TI-Föderation

10.2.4 Beispiel für den Metadatenblock im Entity Statement einer OpenID-Relying-Party

Request zum Abruf Entity Statement

GET /.well-known/openid-federation
Host: idpfadi.dev.gematik.solutions

Response:

Base64 encoded JWT

eyJhbGciOiJFUzI1NiIsInR5cCI6ImVudGl0eS1zdGF0ZW1lbnQrand0Iiwia2lkIjoicHVrX2ZkX3NpZyJ9.eyJpc3MiOiJodHRwczovL2lkcGZhZGkuZGV2LmdlbWF0aWsuc29sdXRpb25zIiwic3ViIjoiaHR0cHM6Ly9pZHBmYWRpLmRldi5nZW1hdGlrLnNvbHV0aW9ucyIsImlhdCI6MTc4MjI5MjQ0NCwiZXhwIjoxNzgyMjk5NjQ0LCJqd2tzIjp7ImtleXMiOlt7ImFsZyI6IkVTMjU2IiwiY3J2IjoiUC0yNTYiLCJraWQiOiJwdWtfZmRfc2lnIiwia3R5IjoiRUMiLCJ1c2UiOiJzaWciLCJ4IjoiOWJKczI3WUFmbE1VV0s1bnh1aUY2WEFHMEphenV2d1JpMUVwRkswWEtpayIsInkiOiJQOGx6TlZST2dUdXdiRHFzZDhyVDFBSTN6ZXo5NEhCc1 ...

Decodierter Header

{ "alg": "ES256",
  "typ": "entity-statement+jwt",
  "kid": "puk_fd_sig" } 

Decodierte Payload

{ "iss": "https://idpfadi.dev.gematik.solutions",
  "sub": "https://idpfadi.dev.gematik.solutions",
  "iat": 1782292444,
  "exp": 1782299644,
  "jwks": {
    "keys":[ {"alg": "ES256", "crv": "P-256", "kid": "puk_fd_sig", "kty": "EC", "use": "sig", "x": "9bJs27YA ...", "y": "P8lzNVRO ..." } ]
  },
  "authority_hints": ["https://app-test.federationmaster.de"],
  "metadata": {
    "openid_relying_party": {
      "signed_jwks_uri": "https://idpfadi.dev.gematik.solutions/jws.json",
      "organization_name": "Fachdienst007 des FedIdp POCs",
      "client_name": "Fachdienst007",
      "logo_uri": "https://idpfadi.dev.gematik.solutions/noLogoYet",
      "redirect_uris": [
        "https://idpfadi.dev.gematik.solutions/auth",
        "https://Fachdienst007.de/client",
        "https://redirect.testsuite.gsi",
        "https://gries.dev.gematik.solutions/callback"
      ],
      "response_types": ["code"],
      "client_registration_types": ["automatic"],
      "grant_types": ["authorization_code"],
      "require_pushed_authorization_requests": true,
      "token_endpoint_auth_method": "self_signed_tls_client_auth",
      "default_acr_values": ["gematik-ehealth-loa-high"],
      "id_token_signed_response_alg": "ES256",
      "id_token_encrypted_response_alg": "ECDH-ES",
      "id_token_encrypted_response_enc": "A256GCM",
      "scope": "urn:telematik:display_name urn:telematik:versicherter openid",
      "ti_features_supported": {
        "id_token_version_supported": [
          "1.0.0",
          "2.0.0"
        ]
      }}}}

Decodierte Payload des von der signed_jwks_uri gelesenes JWT

{ "iss": "https://idpfadi.dev.gematik.solutions",
  "iat": 1782461774,
  "keys": [

{"alg": "ES256", "crv": "P-256", "kid": "puk_tls_sig", "kty": "EC", "use": "sig", "x": "5GqpK6 ...",
      "x5c": [     "MIICOTCCAd+gAwIBAgIUBfjT7ZWKbcyFNmZYPNkxQvtiIOMwCgYIKoZIzj0EAwIwfzELMAkGA1UEBhMCREUxDzANBgNVBAgMBkJlcmxpbjEPMA0GA1UEBwwGQmVybGluMRowGAYDVQQKDBFnZW1hdGlrIE5PVC1WQUxJRDEPMA0GA1UECwwGUFQgSURNMSEwHwYDVQQDDBhmYWNoZGllbnN0VGxzQyBURVNULU9OTFkwHhcNMjQwMTE2MDg0OTU2WhcNMjgwNDI5MDg0OTU2WjB/MQswCQYDVQQGEwJERTEPMA0GA1UECAwGQmVybGluMQ8wDQYDVQQHDAZCZX..." ], "y": "t0QL0 ..." },
  {"alg": "ES256","crv": "P-256","kid": "puk_fd_enc","kty": "EC","use": "enc","x": "NQLaWb ...", "y": "_USgmq ..." }
  ] }

Tabelle 32 : Attribute des Metadatenblocks openid_relying_party der Entity Configuration im .well-known-Dokument eines Fachdienstes als OpenID-Relying-Party in der TI-Föderation

10.2.5 Beispiel für das Entity Statement einer Protected Resource

Decodierte Payload

{{ "iss": "https://popp-ru",
  "sub": "https://popp-ru",
  "iat": 1772008100,
  "exp": 1772094500,
  "jwks": {
    "keys": [{"kty":"EC","crv":"P-256","x":"KyMGY6R4 ...", "y":"MXkEvTog ...", "kid":"cVu2V_js ...", "alg":"ES256", "use":"sig"}]
  },
  "authority_hints": ["https://app-ref.federationmaster.de"],
  "metadata": {
    "oauth_resource": {
      "resource": "https://popp-ru",
      "signed_jwks_uri": "https://popp-ru/.well-known/signed-jwks"
      "organization_name": "PoPP-Service Hersteller"
    }
  },
}

Tabelle 33 : Attribute des Metadatenblocks oauth_resource der Entity Configuration im .well-known-Dokument eines Fachdienstes als Protected Resource in der TI-Föderation

10.2.6 Beispiel eines Subordinate Statement einer OpenID-Relying-Party

Request zum Abruf des Subordinate Statement zu einer OpenID-Relying-Party 

GET /federation/fetch?iss=https://app-test.federationmaster.de &sub=https://idpfadi.dev.gematik.solutions

Host: app-test.federationmaster.de 

Response:

Base64 encoded JWT

eyJ0eXAiOiJlbnRpdHktc3RhdGVtZW50K2p3dCIsImtpZCI6InB1a19mZWRtYXN0ZXJfc2lnIiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJodHRwczovL2FwcC10ZXN0LmZlZGVyYXRpb25tYXN0ZXIuZGUiLCJzdWIiOiJodHRwczovL2lkcGZhZGkuZGV2LmdlbWF0aWsuc29sdXRpb25zIiwiaWF0IjoxNzgyMzcxNTcyLCJleHAiOjE3ODI0NTc5NzIsImp3a3MiOnsia2V5cyI6W3sia3R5IjoiRUMiLCJraWQiOiJwdWtfZmRfc2lnIiwiY3J2IjoiUC0yNTYiLCJ4IjoiOWJKczI3WUFmbE1VV0s1bnh1aUY2WEFHMEphenV2d1JpMUVwRkswWEtpayIsInkiOiJQOGx6TlZST2dUdXdiRHFzZDhyVDFBSTN6ZXo5NEhCc1REcE92YWpQMHJZIiwidXNlIjoic2lnIiwiYWxnIjoiRVMyNTYifV19LCJtZXRhZGF0YSI6eyJvcGVuaWRfcmVse ... 

Decodierter Header

{  "typ": "entity-statement+jwt",
  "kid": "puk_fedmaster_sig",
  "alg": "ES256" }

Decodierter Payload

{ "iss": "https://app-test.federationmaster.de",
  "sub": "https://idpfadi.dev.gematik.solutions",
  "iat": 1782371572,
  "exp": 1782457972,
  "jwks": {
    "keys": [{"kty":"EC", "kid":"puk_fd_sig", "crv": "P-256", "x": "9bJs27Y ...k", "y": "P8lzNVR ...", "use":"sig", "alg":"ES256"} ]
  },
  "metadata": {
    "openid_relying_party": {
      "scope": "urn:telematik:versicherter openid urn:telematik:display_name",
      "claims": [],
      "redirect_uris": [
        "https://Fachdienst007.de/client",
        "https://gries.dev.gematik.solutions/callback",
        "https://idpfadi.dev.gematik.solutions/auth",
        "https://redirect.testsuite.gsi"
    ] } } }

Tabelle 34 : Attribute des Subordinate Statements zu einem Fachdienstes als OpenID-Relying-Party in der TI-Föderation

10.3 Teilnehmer Validierung in der Beispiel TI-Föderation

Vor der Durchführung einer Nutzerauthentifizierung muss ein Fachdienst in seiner Rolle als OpenID-Relying-Party der TI-Föderation die Vertrauensbeziehung zum anfragten sektoralen IDP als OpenID Provider der TI-Föderation validieren.

Ebenso muss der sektorale IDP als OpenID Provider die Vertrauensbeziehung zum Fachdienst validieren.

Abbildung 20 : Aufbau und Validierung der Vertrauensbeziehung zwischen einer OpenID-Relying-Party und einem OpenID Provider

Die Prüfung der Entity Statements und Subordinate Statements erfolgt nach den Vorgaben [OpenID Federation 1.1] (Entity Statement Validation).

Sind alle Schritte erfolgreich, so ist die Vertrauensbeziehung zwischen Fachdienst als Relying Party und sektoralen IDP bestätigt.

10.3.1 OpenID-Relying-Party prüft das Entity Statement des OpenID Provider

Der Identifikator (iss) des sektoralen IDP in seiner Rolle als OpenID Provider der TI-Föderation wird der OpenID-Relying-Party durch den Fachdienst-Client im Rahmen der Authentifizierungsanfrage übermittelt.

Die OpenID-Relying-Party lädt anschließend die Entity Configuration des sektoralen IDP über den Endpunkt /.well-known/openid-federation und validiert das enthaltene Entity Statement gemäß den in [OpenID Federation 1.1] definierten Validierungsvorschriften.

Dabei werden die für die Validierung eines Entity Statements erforderlichen Prüfschritte durchgeführt.

Im dargestellten Beispiel sind die folgenden Claims nicht enthalten

• trust_anchor_hints
• metadata_policy
• metadata_policy_crit
• constraints 
• trust_marks
• trust_mark_issuers
• trust_mark_owners
• source_endpoint

Die in [OpenID Federation 1.1] für diese Claims definierten Prüfschritte entfallen daher.

Ebenso sind die folgenden Header-Parameter im Beispiel nicht enthalten

• trust_chain
• peer_trust_chain

Die hierfür vorgesehenen Prüfschritte entfallen ebenfalls.

Tabelle 35 : Prüfschritte zur Validierung des Entity Statements eines OpenID Providers

10.3.2 OpenID-Relying-Party prüft das Entity Statement des Trust Anchor

Den Identifikator (iss) des Federation Masters extrahiert die OpenID-Relying-Party aus dem Claim authority_hints des Entity Statements des sektoralen IDP.

Anschließend lädt die OpenID-Relying-Party die Entity Configuration des Federation Masters als Trust Anchor über den Endpunkt /.well-known/openid-federation und validiert das enthaltene Entity Statement gemäß den Vorgaben aus [OpenID Federation 1.1].

Dabei werden die für die Validierung eines Entity Statements erforderlichen Prüfschritte durchgeführt.

Im dargestellten Beispiel sind die folgenden Claims nicht enthalten:

• trust_anchor_hints
• metadata_policy
• metadata_policy_crit
• constraints 
• trust_marks
• trust_mark_issuers
• trust_mark_owners
• source_endpoint

Die für diese Claims vorgesehenen Prüfschritte entfallen daher.

Ebenso sind die folgenden Header-Parameter nicht enthalten:

• trust_chain
• peer_trust_chain

Die hierfür vorgesehenen Prüfschritte entfallen ebenfalls.

Tabelle 36 : Prüfschritte zur Validierung des Entity Statements des Federation Masters als Trust Anchor

Schritt 10 ist die Besonderheit bei der Validierung des Trust Anchors. Während bei normalen Entitäten die Vertrauenskette bis zum Trust Anchor aufgebaut wird, wird beim Trust Anchor zusätzlich geprüft, dass der veröffentlichte Signaturschlüssel demjenigen Schlüssel entspricht, der dem Teilnehmer während des Registrierungsprozesses als Vertrauensanker bekannt gemacht wurde. Dadurch entsteht der Vertrauensanker der gesamten Föderation.

10.3.3 OpenID-Relying-Party prüft Subordinate Statement zum OpenID Provider

Den Identifikator des Federation Masters extrahiert der Fachdienst in seiner Rolle als OpenID-Relying-Party der TI-Föderation aus dem Claim authority_hints des Entity Statements des sektoralen IDP.

Anschließend ruft die OpenID-Relying-Party beim Federation Master als Trust Anchor das Subordinate Statement des sektoralen IDP ab. Die hierfür benötigte URL wird aus dem Claim federation_fetch_endpoint der Entity Configuration des Federation Masters ermittelt.

Die OpenID-Relying-Party validiert das Subordinate Statement gemäß den Vorgaben aus [OpenID Federation 1.1].

Dabei werden die für die Validierung eines Subordinate Statements erforderlichen Prüfschritte durchgeführt.

Im dargestellten Beispiel sind die folgenden Claims nicht enthalten:

• trust_anchor_hints
• metadata_policy
• metadata_policy_crit
• constraints 
• trust_marks
• trust_mark_issuers
• trust_mark_owners
• source_endpoint

Die für diese Claims vorgesehenen Prüfschritte entfallen daher.

Ebenso sind die folgenden Header-Parameter nicht enthalten:

• trust_chain
• peer_trust_chain

Die hierfür vorgesehenen Prüfschritte entfallen ebenfalls.

Der Claim authority_hints ist in einem Subordinate Statement nicht enthalten und wird daher nicht geprüft.

Tabelle 37 : Prüfschritte zur Validierung des Subordinate Statements eines sektoralen IDP

Der Prüfschritt 9 ist für die OpenID Federation besonders wichtig. Durch den Vergleich des jwks-Claims im Entity Statement mit dem jwks-Claim im Subordinate Statement wird sichergestellt, dass die öffentlichen Federation-Entity-Signing-Keys des sektoralen IDP durch den Federation Master autorisiert wurden. Dadurch entsteht die eigentliche Vertrauensbeziehung zwischen dem sektoralen IDP und dem Trust Anchor der TI-Föderation.

10.3.4 OpenID Provider prüft das Entity Statement der OpenID-Relying-Party

Den Identifikator (iss) des Fachdienstes in seiner Rolle als OpenID-Relying-Party der TI-Föderation extrahiert der sektorale IDP aus dem Pushed Authorization Request der OpenID-Relying-Party.

Anschließend lädt der sektorale IDP in seiner Rolle als OpenID Provider die Entity Configuration des Fachdienstes über den Endpunkt /.well-known/openid-federation und validiert das enthaltene Entity Statement gemäß den Vorgaben aus [OpenID Federation 1.1].

Dabei werden die für die Validierung eines Entity Statements erforderlichen Prüfschritte durchgeführt.

Im dargestellten Beispiel sind die folgenden Claims nicht enthalten:

• trust_anchor_hints
• metadata_policy
• metadata_policy_crit
• constraints 
• trust_marks
• trust_mark_issuers
• trust_mark_owners
• source_endpoint

Die für diese Claims vorgesehenen Prüfschritte entfallen daher.

Ebenso sind die folgenden Header-Parameter nicht enthalten:

• trust_chain
• peer_trust_chain

Die hierfür vorgesehenen Prüfschritte entfallen ebenfalls.

Tabelle 38 : Prüfschritte zur Validierung des Entity Statements einer OpenID-Relying-Party

10.3.5 OpenID Provider prüft das Entity Statement des Trust Anchor

Den Identifikator (iss) des Federation Masters extrahiert der OpenID Provider aus dem Claim authority_hints des Entity Statements der OpenID-Relying-Party.

Anschließend lädt der sektorale IDP in seiner Rolle als OpenID Provider die Entity Configuration des Federation Masters als Trust Anchor über den Endpunkt /.well-known/openid-federation und validiert das darin enthaltene Entity Statement gemäß den Vorgaben aus [OpenID Federation 1.1].

Dabei werden die für die Validierung eines Entity Statements erforderlichen Prüfschritte durchgeführt.

Im dargestellten Beispiel sind die folgenden Claims nicht enthalten:

• trust_anchor_hints
• metadata_policy
• metadata_policy_crit
• constraints 
• trust_marks
• trust_mark_issuers
• trust_mark_owners
• source_endpoint