gemSpec_IDP_FedMaster_V1.4.3

PDF HTML Excel XML
Zurück nach oben






Elektronische Gesundheitskarte und Telematikinfrastruktur





Spezifikation

Federation Master




Version1.4.3
Revision1658475
Stand10.07.2026
Statusfreigegeben
Klassifizierungöffentlich
ReferenzierunggemSpec_IDP_FedMaster


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

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Version
Stand
Kap./ Seite
Grund der Änderung, besondere Hinweise
Bearbeitung
1.0.0 06.02.2023 Einarbeitung Release FedMaster gematik
1.1.0 01.09.2023 Einarbeitung IdP_Maintenance_23.4 gematik
1.2.0 30.01.2024 Einarbeitung ePAfueralle gematik
1.3.0 05.04.2024 Einarbeitung IDP_24_5 gematik
1.4.0 14.02.2025 Einarbeitung IDP_24_10 gematik
1.4.1 27.02.2025 Redaktionelle Änderung gematik
1.4.2 14.11.2025 Einarbeitung IDP_25_6 gematik
1.4.3 10.07.2026 Einarbeitung IDP_26_1 gematik


Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Produkttyps Superior. Der Produkttyp TI-Föderation Superior  basiert auf dem Standard [OpenID Federation 1.1] und unter Berücksichtigung weiterer Standards wie OpenID Connect (OIDC), Open Authorization 2.0 (OAuth 2) und JSON Web Token (JWT). Superior Entities nach [OpenID Federation 1.1] sind entweder die Vertrauensanker (Trust Anchor) oder bestimmte Knotenpunkte (Intermediate)  der TI-Föderation. Superior Entities  stellen Schnittstellen bereit,  welche Auskunft über die in der Föderation registrierten Teilnehmer geben. Die Kernaufgaben der Superior Entities sind:

  • Verwaltung der öffentlichen Schlüssel aller in der Föderation registrierten Teilnehmer (OpenID Provider (OP), Relying Party (RP) und OAuth-Protected Resources (RS) gemäß Spezifikation [OpenID Connect Core 1.0])
  • Validierung von Anfragen über Teilnehmer der Föderation
  • Bereitstellung von Schnittstellen für:
    • die Auskunft zur Superior Entity (Entity Statement)
    • die Auskunft über Teilnehmer der Föderation (Subordinate Statement)
    • die Auskunft über die Liste aller registrierten OpenID Provider (OP)
    • die Registrierung neuer Teilnehmer (Intermediate, OP, RP und RS)
    • das Löschen von nicht mehr benötigten Teilnehmern (Intermediate, OP, RP und RS)

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter, welche die Funktionen des Produkttyps Federation Master der gematik realisieren wollen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur (TI) des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

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 Abgrenzungen

Nicht Bestandteil des vorliegenden Dokumentes sind die Verfahrensschritte zur Erstellung des notwendigen Schlüsselmaterials. Für die Signatur des Entity Statement wird angenommen, dass die OpenID Provider (OP) und Relying Parties (RP) der Föderation ihre innerhalb der TI zu verwendenden Zertifikate für die Transport Layer Security (TLS)-Sicherung über zentrale Plattformdienste der TI beziehen und diese dort auch geprüft werden können.

Als Umsetzungsleitlinie ist [OpenID Connect Core 1.0] und [OpenID Federation 1.1] heranzuziehen. Die TI-weit übergreifenden Festlegungen – insbesondere aus Dokumenten wie beispielsweise [gemSpec_Krypt] bezüglich Algorithmen und Schlüsselstärken sowie [gemSpec_PKI] bezüglich zu verwendender Zertifikatstypen und deren Attributausprägungen – haben Bestand, sind ebenso bindend und werden nicht in diesem Dokument beschrieben.

Ebenfalls nicht Bestandteil dieses Dokuments ist die Beschreibung des Gesamtsystems der TI-Föderation. Hier wird auf [gemKPT_TI-Föderation] verwiesen. In diesem Dokument ist die Motivaton sowie die Architektur der TI-Föderation ausführlich dargelegt.

Für weitere Komponenten der TI-Föderation gelten eigene Spezifikationsdokumente:

  • sektorale Identity Provider - [gemSpec_IDP_Sek]
  • Fachdienste - [gemSpec_IDP_FD]
  • Anwendungsfrontend der Fachdienste - [gemSpec_IDP_Frontend].

1.5 Methodik

1.5.1 Anforderungen

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:
<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und der Textmarke [<=] angeführten Inhalte.

1.5.2 Anwendungsfälle und Akzeptanzkriterien

Anwendungsfälle und Akzeptanzkriterien als Ausdruck normativer Festlegungen werden als Grundlage für Erlangung der Zulassung durch Tests geprüft und nachgewiesen. Sie besitzen eine eindeutige, permanente ID, welche als Referenz verwendet werden SOLL. Die Tests werden gegen eine von der gematik gestellte Referenz-Implementierung durchgeführt. 

Anwendungsfälle und Akzeptanzkriterien werden im Dokument wie folgt dargestellt:
<ID> - <Titel des Anwendungsfalles / Akzeptanzkriteriums>
Text / Beschreibung
[<=]

Die einzelnen Elemente beschreiben:

  • ID: einen eindeutigen Identifier.
    • Bei einem Anwendungsfall besteht der Identifier aus der Zeichenfolge 'AF_' gefolgt von einer Zahl, 
    • Der Identifier eines Akzeptanzkriteriums wird von System vergeben, z.B. die Zeichenfolge 'ML_' gefolgt von einer Zahl
  • Titel des Anwendungsfalles / Akzeptanzkriteriums: Ein Titel, welcher zusammenfassend den Inhalt beschreibt
  • Text / Beschreibung: Ausführliche Beschreibung des Inhalts. Kann neben Text Tabellen, Abbildungen und Modelle enthalten

Dabei umfasst der Anwendungsfall bzw. das Akzeptanzkriterium sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

Der für die Erlangung einer Zulassung notwendige  Nachweis der Erfüllung des Anwendungsfalls wird in den jeweiligen  Steckbriefen festgelegt, in denen jeweils der Anwendungsfall gelistet ist. Akzeptanzkriterien werden in der Regel nicht im Steckbrief gelistet.

1.5.3 Hinweise

Hinweis auf offene Punkte

Offener Punkt: Das Kapitel wird in einer späteren Version des Dokumentes ergänzt.

2 Systemüberblick

In [gemKPT_TI-Föderation] ist das Konzeptes zur TI-Föderation hinsichtlich Motivation, Architektur und Beispielen ausführlich beschrieben. Für den Überblick über das Gesamtsystem sowie über Akteure, Rollen, Schnittstellen und Abläufe wird deshalb auf dieses Dokument verwiesen.

3 Funktionsmerkale

Die Anwendugsfälle der TI-Föderation sind in [gemKPT_TI-Föderation] im Kapitel "Anwendungsfälle" ausführlich beschrieben.  Tabelle "Anwendungsfälle mit Beteiligung von Superior Entities (Federation Master / Intermediate)" listet die Anwendungsfälle, die von Federation Master oder Intermediates in der TI-Föderation bereitgestellt weren müssen.

Tabelle 1: Anwendungsfälle mit Beteiligung von Superior Entities (Federation Master / Intermediate)

Typ Anwendungsfall
Technisch IDP-Liste bereitstellen
Technisch Subordinate Statement bereitstellen  
Technisch Schlüssel verwalten
Technisch / Organisatorisch Schlüssel der TLS-Zertifikate abgleichen 
Organisatorisch Teilnehmer registrieren
Organisatorisch Teilnehmer löschen 


Die technischen Anwendungsfälle werden hier im Detail beschrieben. Details zu den organisatorischen Anwendungsfällen finden sich in Kapitel [4.2.1 Organisatorische Prozesse].

Abbildung 1: Federation Master im Authorization-Flow

Tabelle 2: Federation Master im Authorization-Flow

Schritt Beteiligte Parteien Beschreibung
1 - getEntityStatement(FM) sektoraler Identity Provider, Federation Master Request zum Abholen des Entity Statement des Federation Master am Endpunkt  
.well-known/openid-federation
des Federation Masters durch den sektoralen Identity Provider.
2 - getEntityStatement(FM) Fachdienst, Federation Master Request zum Abholen des Entity Statement des Federation Master am Endpunkt  
.well-known/openid-federation
des Federation Masters durch den Fachdienst.
3 - getIdpListe Fachdienst, Federation Master Request zum Abholen der Liste der in der Föderation registrierten sektoralen Identity Provider vom Federation Master durch den Fachdienst am idp_list_endpoint  Endpunkt des Federation Masters.
4 - getEntityStatement(IDP) Fachdienst, sektoraler Identity Provider Request zum Abholen des Entity Statement des sektoralen Identity Provider vom sektoralen Identity Provider durch den Fachdienst
5 - fetchEntityStatement(IDP) Fachdienst, Federation Master validieren des sektoralen Identity Provider als Teilnehmer der Föderation beim Federation Master durch den Fachdienst am Endpunkt federation_fetch_endpoint des Federation Masters.
6 - getEntityStatement(FD) sektoraler Identity Provider, Fachdienst Request zum Abholen des Entity Statement des Fachdienstes vom Fachdienst durch den sektoralen Identity Provider.
7 - fetchEntityStatement(FD) sektoraler Identity Provider, Federation Master validieren des Fachdienstes als Teilnehmer der Föderation beim Federation Master durch den sektoralen Identity Provider am Endpunkt federation_fetch_endpoint des Federation Masters.

Hinweis: Eine detaillierte Beschreibung der Verwendung des OAuth- und OIDC-Standards ist nicht Teil dieser Spezifikation. Die diesbezüglichen Schritte im Flow werden nicht weiter erläutert.

3.1 Anwendungsfall - Subordinate Statement bereitstellen

AF_10101-02 - Bereitstellung von Informationen zu Teilnehmern der Föderation (Subordinate Statement)

Tabelle 3: Anwendungsfall "Bereitstellung von Informationen zu Teilnehmern der Föderation durch eine Superior Entity"

Attribute Bemerkung
Beschreibung Der Nutzer einer Anwendung der Föderation muss durch die Anwendung autorisiert werden. Im Zuge des Autorisierungsablaufs wird der Nutzer über einen sektoralen Identity Provider authentifiziert. Im Ablauf dieses Authorization-Flow einer Anwendung wird die Superior Entity (Federation Master oder Intermediate), bei welcher der Fachdienst Authorization Server registriert ist, zur Validierung der teilnehmenden Parteien einbezogen. Die Abbildung "Federation Master und Intermediate im Authorization-Flow" zeigt die Schritte im Flow, bei denen eine Kommunikation mit der Superior Entity  stattfindet.
Akteur Anwender der Fachanwendung
Auslöser Ein Anwender möchte eine Gesundheitsanwendung der TI (Fachdienst) nutzen und muss dafür gegen einen sektoralen Identity Provider der TI authentifiziert werden.
Komponente
  • Superior Entity (Federation Master oder Intermediate)
  • Fachdienst Authorization Server eines Fachdienstes der TI
  • sektoraler Identity Provider
Vorbedingung
  • Der Fachdienst Authorization Server ist bei einer Superior Entity der TI-Föderation registriert und sein öffentlicher Schlüssel und sein Entity Statement sind bei der Superior Entity hinterlegt. 
  • Der sektorale Identity Provider ist beim Federation Master in der TI-Föderation registriert und sein öffentlicher Schlüssel und sein Entity Statement sind beim Federation Master hinterlegt.
  • Das Entity Statement der Superior Entity wurde vom Teilnehmer geladen. Die in der Entity Configuration der Superior Entity unter dem Attribut federation_fetch_endpoint benannte URL ist aus dem Internet erreichbar. 
Ablauf
  • Im Ablauf der Nutzung eines Fachdienstes (siehe Abbildung  - Flow-Diagramm  "Federation Master  und Intermediate im Authorization-Flow") findet eine Verzweigung zu einer Superior Entity (Federation Master oder Intermediate) in dem Fall statt, wenn der Fachdienst Authorization Server das Entity Statement des sektoralen Identity Provider oder wenn der sektorale Identity Provider das Entity Statement des Fachdienst Authorization Server nicht kennt.
  • Für die Abfrage von Informationen zu einem Teilnehmer der TI-Föderation bei einer Superior Entity sendet der anfragende Teilnehmer einen Request an die unter federation_fetch_endpoint im Entity Statement der Superior Entity  festgelegte URL. Der Request MUSS die in Tabelle "Teilnehmer Validierung Abfrage - Request Parameter"  Parameter umfassen.
  • Die Superior Entity MUSS als Response auf die Anfrage des Fachdienstes ein signiertes JSON Web Token senden (Subordinate Statement). Die Header- und Payload-Attribute des JWS MÜSSEN mindestens die in den Tabellen "Teilnehmer Validierung Abfrage - Response-Payload-Attribute des signierten JSON-Web-Token" und "Teilnehmer Validierung Abfrage - Response-Header-Attribute des signierten JSON-Web-Token" aufgeführten Attribute enthalten.

Ergebnis Der anfragende Teilnehmer hat Informationen über den angefragten Teilnehmer erhalten, kann diese entschlüsseln und verwenden.
Akzeptanzkriterien ML-190119 - AF_10101 - Request von Teilnehmern an die im federation_fetch_endpoint benannte URL der Superior Entity 
ML-190120 - AF_10101 - Unter federation_fetch_endpoint benannte URL ist erreichbar und liefert signiertes JWS als Response 
ML-190121 - AF_10101 - Payload des JWS-Token enthält Informationen zum angefragten Teilnehmer der TI-Föderation 
Alternativen Der Anwendungsfall entfällt, wenn die Teilnehmer sich kennen, eine gegenseitige Validierung bereits früher erfolgt ist und eine erneute Validierung (noch) nicht notwendig ist.

Tabelle 4: Subordinate Statement - Request-Parameter (Subordinate Statement) gemäß [OpenID Federation 1.1] - "Fetch Subordinate Statement Request"

Attribut Werte / Typ Anmerkung
iss (deprecated)* string,
URL nach [RFC1738] 		 Identifier (iss) der Spuperior Entity  (Federation Master oder Intermediate), bei welcher die Subordinate Entity registriert ist
sub string,
URL nach [RFC1738] 		 Identifier (iss) des angefragten Teilnehmers aus dessen Entity Statement
aud (deprecated)* string,
URL nach [RFC1738] 		 Identifier (iss) des angefragten Teilnehmers aus dessen Entity Statement
Wird dieser claim nicht gesetzt, so kann alternativ die bei der Registrierung des Fachdienstes/IDP vergebene Member-ID im UserAgent gesetzt werden.

(*) Nach finaler Version [OpenID Federation 1.1] sind die Parameter "iss" und "aud" nicht mehr notwenig. Subordinate Entities müssen die Schnittstelle mit und ohne die deprecated-Parameter unterstützen, bis alle Teilnehmer ihre Requests konform zum aktuellen Standard erstellen.

Tabelle 5: Subordinate Statement  - Response-Payload-Attribute des signierten JSON-Web-Token

Attribut Werte / Typ Anmerkungen
iss string,
URL nach [RFC1738] 		 Identifier (iss) der Spuperior Entity  (Federation Master oder Intermediate), bei welcher die Subordinate Entity registriert ist
sub string,
URL nach [RFC1738] 		 Identifier (iss) des angefragten Teilnehmers aus dessen Entity Statement
iat Alle time Werte in Sekunden seit 1970, [RFC7519#section-2] Ausstellungszeitpunkt des Subordinate Statement
exp Alle time Werte in Sekunden seit 1970, [RFC7519#section-2] Ablaufzeitpunkt der Gültigkeit des Subordinate Statement
jwks Set von JWK [RFC7517]
zulässige Werte sind, gemäß [OpenID Federation 1.1  ] - jwks, nur die öffentlichen Schlüssel zu Schlüsseln, mit denen das Entity Statement signiert ist (Federation Entity signing key).		 Öffentlicher Schlüssel, mit dem der angefragte Teilnehmer sein Entity Statement signiert (Federation-Entity-Signing-Key).


Folgende Werte müssen Bestandteil des Header der vom Federation Master signierten Informationen zu Teilnehmern der TI-Föderation sein:

Tabelle 6: Subordinate Statement  - Response-Header-Attribute des signierten JSON-Web-Token

Name Werte Anmerkungen
alg string,
zulässiger Wert: "ES256" 
kid string
UUID7-Format [RFC9562#name-uuid-version-7] 		 Identifier des verwendeten Schlüssels aus dem jwks im Body des Statement
typ entity-statement+jwt 

[<=]

3.1.1 Akzeptanzkriterien - Subordinate Statement bereitstellen

ML-190119 - AF_10101 - Request von Teilnehmern an die im federation_fetch_endpoint benannte URL der Superior Entity

Der Request eines in der TI-Föderation registrierten Teilnehmers an die im Entity Statement der Superior Entity, bei welcher der Teilnehmer registriert ist (Federation Master oder Intermediate), unter dem Claim federation_fetch_endpoint benannte URL SOLL die in der Tabelle "Teilnehmer Validierung Abfrage - Request-Parameter" aufgeführten Claims enthalten. Ist der aud-Parameter im Subordinate-Statement-Request des anfragenden Teilnehmers nicht gesetzt, so SOLL die Member-ID als User Agent im Request Header gesetzt sein. Ist weder der aud-Parameter noch der User Agent gesetzt, MUSS trotzdem ein Subordinate Statement zum angefragten Teilnehmer vom Federation Master zurückgeliefert werden. [<=]

ML-190120 - AF_10101 - Unter federation_fetch_endpoint benannte URL ist erreichbar und liefert signiertes JWS als Response

Der Request eines Teilnehmers der TI-Föderation an die URL, welche im Entity Statement der Superior Entity, bei welcher der Teilnehmer registriert ist (Federation Master oder Intermediate), unter dem Attribut federation_fetch_endpoint benannt ist, wird entgegen genommen und gibt als Response ein signiertes JWT (Subordinate Statement) zurück. Das Token ist mit dem privaten Schlüssel der Superior Entity signiert und kann vom Teilnehmer der TI-Föderation mit dem öffentlichen Schlüssel der Superior Entity verifiziert werden. [<=]

ML-190121 - AF_10101 - Payload des JWS-Token enthält Informationen zum angefragten Teilnehmer der TI-Föderation

Der Payload des JWS-Token (Subordinate Statement) enthält diese Informationen bezüglich des angefragten Teilnehmers der TI-Föderation:

  • iss = URL - Identifier Federation Master
  • sub = URL - Identifier des angefragten Teilnehmers 
  • iat = long Wert - Ausstellungszeitpunkt des Abrufs (alle time-Werte in Sekunden seit 1970) 
  • exp = long Wert - Ablaufzeitpunkt der Gültigkeit des Abrufs (alle time-Werte in Sekunden seit 1970) 
  • jwks = JWKS-Objekt - öffentliche Schlüssel der Federation-Entity-Signing-Keys des angefragten Teilnehmers
Für registrierte Fachdienste als Relying Parties der TI-Föderation MÜSSEN zusätzlich diese Informationen enthalten sein:
  • metadata = JSON Object mit folgenden Metadaten 
  • openid_relying_party = JSON Object mit folgenden Metadaten, die eine Relying Party in ihrem Entity Statement ausweisen muss 
  • scope = Scope, die bei der Registrierung der Relying Party bei der Superior Entity angegeben wurden 
  • claims = Claims, die bei der Registrierung der Relying Party der Superior Entity angegeben wurden 
  • redirect_uris = redirect_uris, die bei der Registrierung der Relying Party der Superior Entity angegeben wurden
[<=]

Hinweis: Für den Fetch Entity Request gelten die Festlegung im Standard [OpenID Connect Federation1.0#Kapitel 7.1.1]. 

Hinweis: Will eine Relying Party den Umfang der vom sektoralen IDP anforderbaren Scopes oder Claims erweitern oder redirect_uris ändern, so müssen diese Änderungen über den organisatorischen Registrierungsprozess laufen.

3.2 Anwendungsfälle - Trust Anchor (Federation Master)

Diese Kapitel beschreibt die Anwendungsfälle, welche nur durch den Trust Anchor (Federation Master) bereitzustellen sind.

3.2.1 Anwendungsfall - IDP-Liste bereitstellen

Abbildung 2:  Aktivitätsdiagramm  "Auswahl sektorale Identity Provider"

AF_10100-02 - Bereitstellung Liste registrierter Identity Provider

Tabelle 7: Anwendungsfall "Bereitstellung Liste registrierter Identity Provider"

Attribute Bemerkung
Beschreibung Ein Anwender möchte einen in der TI registrierten Fachdienst nutzen. Der Fachdienst muss sicherstellen, dass der Anwender zur Nutzung des Dienstes berechtigt ist. Um die Berechtigung sicherzustellen, MUSS der Fachdienst die Authentifizierung des Anwenders gegenüber einem sektoralen Identity Provider veranlassen. Dazu benötigt der Fachdienst die Information vom Anwender, gegen welchen sektoralen Identity Provider er sich identifiziert hat.
Der Fachdienst MUSS in seinem Frontend dem Anwender eine Liste, der in der TI registrierten, sektoralen Identity Provider anzeigen. Diese Liste MUSS sich der Fachdienst vom Federation Master erfragen.
Der Federation Master MUSS eine API-Schnittstelle bereitstellen, über die ein Fachdienst die Liste, der in der TI registrierten, sektoralen Identity Provider abfragen kann.
Jeder Listeneintrag MUSS mindestens diese Informationen enthalten:
  • eindeutige issuer-id des sektoralen Identity Provider in der TI-Föderation
  • Name des sektoralen Identity Provider in lesbarer Form
  • Logo des sektoralen Identity Provider (wenn vorhanden).
  • Information, um welchen Typ von Kostenträger es sich handelt
Der Anwender des Fachdienstes MUSS genau einen sektoralen Identity Provider aus der Liste auswählen. Der Fachdienst kann sich die Zuordnung eines Anwenders zu seinem sektoralen Identity Provider speichern, so dass die Abfrage der Liste beim Federation Master nicht bei jeder Anmeldung des Anwenders wiederholt werden muss.
Akteur Anwender der Fachanwendung
Auslöser Ein Anwender möchte eine Gesundheitsanwendung der TI (Fachdienst) nutzen. Als Voraussetzung für die Authentifizierung des Anwenders muss dieser auswählen, bei welchem Identity Provider er registriert ist (bei Versicherten - Auswahl der Krankenkasse).
Komponenten
  • Fachdienst der TI
  • Federation Master
Vorbedingung
  1. Der Fachdienst ist in der TI-Föderation registriert, sein Schlüssel ist dem Federation Master bekannt.
  2. Es gibt eine Liste in der TI-Föderation registrierter (sektoraler) Identity Provider, deren Schlüssel sind dem Federation Master bekannt.
  3. Der Anwender ist durch einen der (sektoraler) Identity Provider identifiziert worden.
  4. Das Entity Statement des Federation Master steht zur Verfügung und die unter dem Attribut idp_list_endpoint benannte URL MUSS aus dem Internet erreichbar sein. 
  5. Der Federartion Master hat die Entity Statements aller registrierten (sektoraler) Identity Provider innerhalb der letzten 24h aktualisiert
Ablauf
  1. Im Ablauf der Nutzung eines Fachdienstes (siehe Abbildung - Aktivitätsdiagramm "Auswahl sektoraler Identity Provider") findet eine Verzweigung zum Federation Master in dem Fall statt, wenn der Fachdienst die Zuordnung des Anwenders zu seinem IDP nicht kennt.
  2. Der Fachdienst sendet einen Request an die URL, welche im Entity Statement des Federation Master unter dem Attribut idp_list_endpoint benannt ist. Der Federation Master nimmt den Request entgegen.
  3. Der Federation Master erstellt eine Liste aller registrierten sektoralen Identity Provider. Die Liste MUSS zu jedem sektoralen Identity Provider diese Attribute enthalten:
    1. Name der Organisation
    2. URI (iss) des sektoralen Identity Provider
    3. Logo der Organisation
    4. Unterstützte Anwendertypen
    5. Information, um welchen Typ von Kostenträger es sich handelt
  4. Der Federation Master MUSS als Response auf die Anfrage des Fachdienstes ein signiertes JSON Web Token senden. Die Header- und Payload-Attribute des JWS MÜSSEN mindestens die in den Tabellen "Liste sektorale Identity Provider - Payload-Attribute des signierten JSON-Web-Token" und "Liste sektorale Identity Provider - Headerattribute des signierten JSON-Web-Token" aufgeführten Attribute enthalten.

Ergebnis
  1. Der Anwender hat aus der Liste, der in der TI registrierten (sektoralen) Identity Provider denjenigen ausgewählt, gegenüber dem er sich zuvor identifiziert hat.
  2. Der Fachdienst hat alle Informationen, um die Authentifizierung und Autorisierung durchzuführen.
Akzeptanzkriterien ML-128409 - AF_10100 - Unter idp_list_endpoint benannte URL ist erreichbar und liefert signiertes JWS als Response,
ML-190096 - AF_10100 - Payload des JWS-Token enthält Informationen zu jedem registrierten sektoralen Identity Provider der Föderation 
Alternativen Die Fachanwendung kennt (z.B. aus früheren Sitzungen) den sektoralen Identity Provider des Anwenders. In diesem Fall KANN der Anwendungsfall ausgeführt werden.

Tabelle 8: Liste sektorale Identity Provider - Payload-Attribute des signierten JSON-Web-Token

Attribut Werte / Typ Anmerkungen
iss string,
URL nach [RFC1738] 		 URL des Federation Master
iat number,
Alle time-Werte in Sekunden seit 1970, [RFC7519#section-2] 		 Ausstellungszeitpunkt der Liste
exp number,
Alle time-Werte in Sekunden seit 1970, [RFC7519#section-2] 		 Ablaufzeitpunkt der Gültigkeit der Liste
idp_entity Der Block idp_entity enthält die Liste der sektoralen Identity Provider und einige Metadaten.
organization_name string (gemäß [OpenID-Federation "Informational Metadata Extensions" ] - organization_name) 
Wertebereich:
^[à-üÀ-Üß\w\ \-\.\+\*\/]{1,128}$ 		 Der Name des sektoralen Identity Provider zur Anzeige für den Benutzer wird aus dem Parameters organization_name im Entity Statement des sektoralen Identity Provider ermittelt.
iss string,
URL nach [RFC1738]  		 Der issuer-Wert des jeweiligen sektoralen Identity Provider (URL) entspricht dem Parameters iss im Entity Statement des sektoralen Identity Provider.
logo_uri URI
zulässige Formate: PNG		 Der Wert für "logo_uri" wird aus dem Parameters logo_uri im Entity Statement des sektoralen Identity Provider ermittelt.
user_type_supported [string]
zulässiger Wert: "IP" (Insured Person) 		 Der Wert für "user_type_supported" wird aus dem Parameters user_type_supported  im Entity Statement des sektoralen Identity Provider ermittelt.
pkv (deprecated) boolean,
Wertebereich: true/false 		 Signalisiert, ob der Föderationsteilnehmer Teil der privaten Krankenversicherungen ist.
Der Parameter entfällt nach vollständiger Umstellung auf ktr_type nach einer Karenzzeit in einer weiteren Stufe..
ktr_type [string], 
Wertebereich:"pkv", "gkv", "hlf"		 Signalisiert, welcher Typ Kostenträger den sektotalen IDP in der TI-Föderation stellt. 
  • gkv - gesetzliche Krankenversicherungungen
  • pkv - private Krankenversicherungen
  • hlf - Heilfürsorge (Bundespolizei)


Folgende Werte müssen Bestandteil des Header der vom Federation Master signierten IDP-Liste sein:

Tabelle 9: Liste sektorale Identity Provider - Headerattribute des signierten JSON-Web-Token

Name Werte Anmerkungen
alg string,
zulässiger Wert "ES256"
kid string
UUID7-Format [RFC9562#name-uuid-version-7]		 Identifier des federation_entity_signing_key des Federation Master. Der Schlüssel kann aus dem jwks im Body des Entity Statement des Federation Master ermittelt werden.
typ idp-list+jwt 

[<=]

3.2.1.1 Akzeptanzkriterien - IDP-Liste bereitstellen

ML-128409 - AF_10100 - Unter idp_list_endpoint benannte URL ist erreichbar und liefert signiertes JWS als Response

Der Request vom Fachdienst an URL, welche im Entity Statement des Federation Master unter dem Attribut idp_list_endpoint benannt ist, wird entgegengenommen und gibt als Response ein signiertes JWS zurück. Das Token ist mit dem privaten Schlüssel des Federation Master signiert und kann vom Fachdienst mit dem öffentlichen Schlüssel des Federation Master verifiziert werden. [<=]

ML-190096 - AF_10100 - Payload des JWS-Token enthält Informationen zu jedem registrierten sektoralen Identity Provider der Föderation

Der Payload des JWS-Token enthält zu jedem in der Föderation registrierten sektoralen Identity Provider die Informationen:

  • Organisationsname
  • URL, unter welcher das Logo der Organisation abrufbar ist
  • URI des sektoralen Identity Provider, welcher dem Identifier (iss) des sektoralen Identity Provider entspricht
  • Liste der supporteten Usertype
  • Information, um welchen Typ von Kostenträger es sich handelt
[<=]

3.2.2 Anwendungsfall - Schlüssel verwalten

AF_10110 - Monitoring der TLS- Zertifikate der VAU


Abbildung 3: Prüfung der TLS-Zertifikate eines sektoralen Identity Provider am Federation Master


Tabelle 10: Anwendungsfall "Monitoring der TLS-Zertifikate der VAU"

Attribute Bemerkung
Beschreibung Certificate Transparency Monitor für die TLS-Zertifikate
Akteur Federation Master
Auslöser
  • Ein TLS-Zertifikat für eine Domäne, welche in der VAU des jeweiligen sektoralen IDP-Dienstes mündet, wird erstellt. 
  • Regelmäßige Prüfung der veröffentlichten TLS-Zertifikate
Komponente
  • Federation Master
  • sektoraler Identity Provider
Vorbedingung Der sektorale Identity Provider ist in der TI-Föderation registriert. Bei neu erstellten TLS-Zertifikaten wurde der Prozess [Certificate Transparency TLS-Zertifikate der sektoralen Identity Provider prüfen]  erfolgreich durchlaufen. Die öffentlichen Schlüssel des sektoralen Identity Provider und seine öffentliche TLS-Schlüssel sind beim Federation Master hinterlegt.
Ablauf Der Federation Master MUSS einen Certificate Transparency Monitor für die TLS-Zertifikate der Domains der sektoralen Identity Provider betreiben, die in der VAU des jeweiligen sektoralen IDP-Dienstes münden. In diesem Certificate Transparency Monitor findet der Abgleich der Zertifikate gegen die bekannten Schlüssel der sektoralen Identity Provider statt (RFC9162). Dazu MUSS der Federation Master einmal täglich die TLS-Zertifikate der registrierten sektoralen Identity Provider prüfen. Zu diesem Zweck extrahiert er aus den im Entity Statement des sektoralen Identity Provider hinterlegten Adressen zum Token-, PAR- und  Authorization-Endpunkt die Domänennamen.

Der Federation Master fragt mit allen ermittelten Domänennamen die Schnittstelle mindestens zweier unterschiedlicher öffentlich zugänglicher Provider für Certificate Transparency Records ab (z.B. https://sslmate.com/ct_search_api/).
Die Provider liefern alle registrierten Zertifikate zum Domänennamen.
Der Federation Master MUSS jedes Zertifikat dahingehend prüfen, ob der zugehörige öffentliche Schlüssel beim Federation Master bekannt und damit im HSM der VAU hinterlegt ist.
Ergebnis Bei erfolgreicher Prüfung ist keine Maßnahme seitens Federation Master notwendig. Ist mindestens eine Prüfung negativ, MUSS der Federation Master weitere Schritte hinsichtlich des negativ geprüften sektoralen Identity Provider einleiten und einen "Security Incident" (gemäß 3.4 aus [gemRL_Betr_TI]) erstellen.
Akzeptanzkriterien ML-132625 - AF_10110 - Ablage der TLS-Schlüssel im Federation Master, ML-132627 - AF_10110 - TLS-Schlüsselprüfung durch den Federation Master nicht erfolgreich 
Alternativen -
[<=]

3.2.2.1 Akzeptanzkriterien - Schlüssel verwalten

ML-132625 - AF_10110 - Ablage der TLS-Schlüssel im Federation Master

Wurde ein sektoraler Identity Provider erstmalig beim Federation Master registriert, so MÜSSEN die öffentlichen Schlüssel aller TLS-Zertifikate zu den second-level, third-level bzw. higher-level domain des sektoralen Identity Provider welche in der VAU terminieren beim Federation Master zum sektoraler Identity Provider hinterlegt sein.
Wurde eine TLS-Zertifikat zu einer second-level, third-level bzw. higher-level domain eines sektoralen Identity Provider, welcher in der VAU terminiert, hinzugefügt oder aktualisiert, so MUSS der öffentliche Schlüssel des hinzugefügten oder aktualisierten TLS-Zertifikats zur Domäne des sektoralen Identity Provider beim Federation Master zum sektoralen Identity Provider hinterlegt sein. [<=]

ML-132627 - AF_10110 - TLS-Schlüsselprüfung durch den Federation Master nicht erfolgreich

Gibt es mindestens ein TLS-Zertifikat zu einer second-level, third-level bzw. higher-level domain eines sektoralen Identity Provider, der in der VAU terminiert und dessen öffentlicher Schlüssel nicht oder falsch beim Federation Master registriert ist, so ist die Prüfung nicht erfolgreich. Der Betreiber des Federation Master hat Schritte zur Problemklärung (gemäß A_22968) eingeleitet. [<=]

4 Funktionale Anforderungen

4.1 Allgemeine Anforderungen an Teilnehmer der TI-Föderation

A_28848 - Validierung der Vertrauenskette eines TI-Föderation-Teilnehmers

Teilnehmer der TI-Föderation, welche mit anderen Teilnehmern der TI-Föderation kommunizieren wollen, MÜSSEN das Entity Statement des anderen TI-Föderation-Teilnehmers abrufen und gemäß der Regeln [OpenID Federation 1.1] ("Entity Statement Validation") validieren, sowie die Vertrauenskette gemäß [OpenID Federation 1.1] ("Resolving the Trust Chain and Metadata") prüfen. Der Abruf des Entity Statement sollte alle 12h und MUSS innerhalb von 24h erfolgen.
[<=]

A_28857 - Maximale Gültigkeitsdauer und regelmäßige Erneuerung des Entity Statement eines TI-Föderation-Teilnehmers

Teilnehmer der TI-Föderation MÜSSEN ihr Entity Statement bei Änderungen oder vor dem zeitlichen Ablaufen neu ausstellen. Die maximale Gültigkeitsdauer - gegeben durch die Differenz der Attributwerte exp-iat - darf 24 Stunden nicht überschreiten. [<=]

A_28859 - Vorlaufzeit bei geplantem Schlüsselwechsel Signaturschlüssel für Entity Statements

Im Rahmen eines geplanten Schlüsselwechsels der Signaturschlüssel MÜSSEN Teilnehmer der TI-Föderation den neuen öffentlichen Signaturschlüssel mindestens 24 Stunden vor der Verwendung im  jwks-Schlüsselsatz im Entity Statement zusätzlich zum aktuell gültigen Signaturschlüssel veröffentlichen. Dieser Signaturschlüssel ist der neue Schlüssel, mit dem der Teilnehmer sein Entity Statement (federation entity signing key) frühestens 24 Stunden nach dieser Veröffentlichung signiert. Der Schlüsselwechsel sollte entsprechend [OpenID Federation 1.1] ("Updating Metadata, Key Rollover, and Revocation") erfolgen.

Hinweis: Nicht betroffen von dieser Anforderung sind kurzfristig notwendige Schlüsselwechsel, z. B. aufgrund von Sicherheitsvorfällen. Diese Maßnahmen sind beispielsweise über Security Incidents abzuwickeln. Die Bearbeitung solcher kurzfristigen Schlüsselwechsel muss die Aktualisierung beim Federation Master bzw. Intermediate mit berücksichtigen, da es ansonsten zu Verarbeitungsfehlern wegen ungültiger Schlüssel kommen kann. [<=]

A_28879 - Registrierung von Teilnehmern in der TI-Föderation durch organisatorischen Prozess

Ein Teilnehmer der TI-Föderation MUSS seinen öffentlichen Schlüssel für die Signatur des selbst-signierten Entity Statement (federation entity signing key) über einen organisatorischen Prozess bei der Superior Entity (Federation Master oder Intermediate) bekannt machen, bei welcher der Teilnehmer als Subordinate Entity registriert werden soll. Nach erfolgreicher Registrierung wird dem Teilnehmer der öffentliche Schlüssel übermittelt, mit dem das Entity Statement des Federation Master signiert ist (federation entity signing key). Der Teilnehmer MUSS diesen Schlüssel speichern und zur Validierung einer Vertrauenskette gemäß A_28848* verwenden. [<=]

A_29019 - Abruf eines Subordinate Statement abweichend von OpenID Federation 1.1 (befristet)

Der Abruf eines Subordinate Statement eines Teilnehmers zu einem anderen Teilnehmer bei dessen Superior Entity MUSS abweichend zu [OpenID Federation 1.1]  ("Fetch Subordinate Statement Request") ein HTTP-GET Request mit folgenden Parametern an den federation_fetch_endpoint der Superior Entity sein:

Tabelle 11: Teilnehmer Validierung Abfrage - Request-Parameter

Attribut Werte / Typ Anmerkung
iss string,
URL nach [RFC1738]		 Identifier (iss) der Subordinate Entity (Federation Master oder Intermendiate-Entity), bei welcher der Teilnehmer (sub) registriert ist.
sub string,
URL nach [RFC1738] 		 Identifier (iss) des angefragten Teilnehmers aus dessen Entity Statement

Hinweis: Eine Umstellung auf den aktuellen Standard entsprechend [OpenID Federation 1.1 ] ("Fetch Subordinate Statement Request") kann erst erfolgen, wenn die API des Federation Master angepasst wurde. [<=]

4.2 Anforderungen an Superior-Entity (Federation Master, Intermediate)

Superior Entities sind gemäß [OpenID Federation 1.1] Entitäten in der Hierarchie der TI-Föderation, bei der andere Entitäten (Subordinate Entity) registriert sind. Dabei kann es sich bei den Subordinate Entities um Intermediate oder Leaf Entities (OpenID Provider, OpenID Relying Party, OAuth Resource) handeln.

Der Federation Master ist bei keiner weiteren Superior Entity registriert. Er bildet den Vertrauensanker (Trust Anchor) der TI-Föderation.  Intermediate Entities sind Entitäten, welche Auskunft zu bei ihnen direkt registrierten Teilnehmern geben können (Subordinate Statement). Die Funktionen des Federation Master und der Intermediates sind in der TI-Föderation nahezu gleich. Der Funktionsumfang des Federation Master ist spezifisch für die TI-Föderation erweitert.

Gemäß der verwendeten Standards OpenID Federation 1.1, OpenID Connect und OAuth 2.0 kommen JSON Web Token (JWT), JSON Web Encryption (JWE), JSON Web Signature (JWS) und JSON Web Key (JWK) zum Einsatz.

Um den nutzenden Anwendungen eine einheitliche Bezugsquelle für die Adressierung von Schnittstellen zu schaffen, werden die für alle Akteure grundlegenden Schnittstellen in der Entity Configuration zusammengefasst.  Jeder Teilnehmer veröffentlicht seine Entity Configuration als  Entity Statement unter <Teilnehmer URL>/.well-known/openid-federation ([OpenID Federation Kapitel "Entity Statement"]) .

Alle Akteure der TI-Föderation sind angehalten, das Entity Statement herunterzuladen und den Inhalt in den geplanten Betrieb einzubeziehen. Die Teilnehmer der TI-Föderation benötigen die Entity Configuration der Superior Entity zur: 

  • Validierung der Vertrauenskette in der Kommunikation zwischen Fachdienst Authorization Servern, Intermediates und sektoralen Identity Providern
  • Validierung anderer Kommunikationsteilnehmer in der TI-Föderation
  • Ermittlung der API-Endpunkte der Superior Entities

und außerdem bei Bedarf die Entity Configuration des Federation Master zur

  • Ermittlung der Liste aller in der TI-Föderation registrierten sektoralen Identity Provider.

A_22949-01 - Aktualisierungszyklen der Subordinate Statements zu Teilnehmern der TI-Föderation

Federation Master und Intermediates MÜSSEN die Subordinate Statements zu den Teilnehmern der Föderation täglich aktualisieren. Darüber hinaus MÜSSEN Federation Master und Intermediates Subordinate Statement zu einem Teilnehmer bei jeder Änderung aktualisieren, welche sich auf das Subordinate Statement zum Teilnehmer auswirkt. [<=]

Hinweis 1: Ist ein sektoraler IDP ggf. temporär nicht erreichbar, so sollte das Herunterladen des Entity Statements über den Federation Master weiter (z.B. stündlich) versucht werden.

Hinweis 2: Zur Sicherung der Kompatibilität werden für folgende Abweichung erst nach initaler Anpassung aller registrierten Relying Parties Incidents eingestellt:

  • metadata.openid_relying_party.client_name
  • metadata.federation_entity.organization_name.

Hinweis 3: Das Sperren eines Fachdienstes bedeutet technisch den Ausschluss aus der Föderation. Fragt ein sektoraler IDP die Teilnehmerauskunft zu einem gesperrten Fachdienst beim Federation Master ab, so antwortet dieser gemäß [OpenID Connect Federarion 1.0#error_response] mit Error Code HTTP-404 not_found.

Hinweis 4: Zum Entsperren muss der Fachdienst die Abweichungen in seinem Entity Statement korrigieren oder im Fall gewollter Änderungen zur Aktualisierung den organisatorischen Registrierungsprozess erneut durchlaufen.

A_22606-01 - Entity Statement - Prüfung der angebotenen URL

Anbieter des Federation Master oder von Intermediates MÜSSEN alle von ihm im Entity Statement angebotenen URL ständig auf bloße Erreichbarkeit prüfen. [<=]

A_22607-01 - Entity Configuration Inhalte des Federation Master oder Intermediate

Federation Master und Intermediates MÜSSEN ihre Entity Configuration in einem selbst-signierten Entity Statement gemäß [OpenID Federation 1.1] ("Entity Statement") bereitstellen und im Internet verfügbar machen. Das Entity Statement MUSS mindestens die in der folgenden Tabelle aufgeführten Metadaten enthalten: 

Tabelle 12: Header des Entity Statement der Superior Entity

Name Werte / Wertebereich
alg string,
zulässiger Wert "ES256" 
kid string,
UUID7-Format [RFC9562#name-uuid-version-7]
typ string,
zulässiger Wert "entity-statement+jwt"

Tabelle 13 : Allgemeine Attribute  im well-known-Dokument der Superior Entity

Name Werte / Wertebereich 
iss string,
URL nach [RFC1738] 
sub string,
URL nach [RFC1738] 
iat number,
Alle time-Werte in Sekunden seit 1970, [RFC7519#section-2]
exp number,
Alle time-Werte in Sekunden seit 1970, [RFC7519#section-2]
jwks Set von JWK [RFC7517]
zulässige Werte sind, gemäß [OpenID Federation "Claims that MUST or MAY Appear in both Entity Configurations and Subordinate Statements"] - jwks, nur die öffentlichen Schlüssel zu Schlüsseln, mit den das Entity Statement, ein Subordinate Statement und Trust Marks signiert ist (federation entity signing key)
trust_mark_issuers* object (gemäß [Claims that MUST or MAY Appear in Entity Configurations but Not in Subordinate Statements] - trust_mark_issuers
metadata object,
erforderlicher Wert: "federation_entity"

Tabelle 14 :  Attribute des Metadatenblocks federation_entity im well-known-Dokument der Superior Entity

Name Werte
federation_fetch_endpoint string (gemäß [OpenID-Federation "Federation Entity"] - federation_fetch_endpoint) 
URL nach [RFC1738]   
federation_list_endpoint string (gemäß [OpenID-Federation "Federation Entity"] - federation_list_endpoint) 
URL nach [RFC1738]   
federation_historical_keys_endpoint string (gemäß [OpenID-Federation "Federation Entity"] - federation_historical_keys_endpoint) 
URL nach [RFC1738]  
federation_trust_mark_endpoint** string, (gemäß [OpenID-Federation "Federation Entity"] - federation_trust_mark_endpoint) 
URL nach [RFC1738]  
federation_trust_mark_status_endpoint** string, (gemäß [OpenID-Federation "Federation Entity"] - federation_trust_mark_status_endpoint) 
URL nach [RFC1738]  
federation_resolve_endpoint*** string, (gemäß [OpenID-Federation "Federation Entity"] - federation_resolve_endpoint) 
URL nach [RFC1738]  
organization_name string (gemäß [OpenID-Federation "Informational Metadata Extensions" ] - organization_name) 
Wertebereich:
^[à-üÀ-Üß\w\ \-\.\+\*\/]{1,128}$ 
keywords [string] (gemäß [OpenID-Federation "Informational Metadata Extensions" ] - keywords) 
erforderlicher Werte:
"product_type_version:<von der gematik zugelassene Produkttyp-Version>"
"product_type:<von der gematik zugelassener Produkttyp>"
contacts [string] (gemäß [OpenID-Federation "Informational Metadata Extensions" ] - contacts) 
erforderlicher Wert: "<E-Mail-Adresse für Supportanfragen>"
idp_list_endpoint*** string (Adresse des Endpunktes zum Abrufen einer Liste aller sektoraler Identity Provider mit deren Namen, Logo, Identifier und Nutzergruppe gemäß AF_10100*)
URL nach [RFC1738]  

* Der claim trust_mark_issuers ist nur in der Entity Configuration des TrustAnchor (Federation Master) enthalten.
** Diese Endpunkte müssen (nur) bereitgestellt werden, wenn dem Anbieter des Trust Anchor oder Intermediate vom Trust Anchor in dessem trust_mark_issuers das Ausstellen von Trustmarks erlaubt wurde.
*** Der Endpunkt muss ausschließlich durch den TrustAnchor (Federation Master) bereitgestellt werden. Intermediates benötigen diesen Endpunkt nicht. [<=]

A_28912 - Gefilterte Suche nach entity_type und trust_mark_type

Federation Master und Intermediates MÜSSEN die gefilterte Suche nach entity_type und trust_mark_type gemäß [OpenID Federation 1.1] unterstützen.
[<=]

A_23087-01 - Entity Statements gelöschter Teilnehmer

Der Federation Master oder ein Intermediate MUSS sicherstellen, dass der Abruf des Subordinate Statement gelöschter Teilnehmer über das Federation Entity API zu einer Fehlermeldung unter Berücksichtigung des Standards [OpenID Federation 1.1] führt. [<=]

4.2.1 Organisatorische Prozesse

A_22675-03 - Teilnehmerregistrierung am Federation Master und Intermediate

Anbieter des Federation Master und von Intermediates MÜSSEN einen organisatorischen Prozess für die Registrierung von Teilnehmern an der TI-Föderation etablieren. Alle Teilnehmer der TI-Föderation MÜSSEN über diesen Prozess ihre öffentlichen Schlüssel beim übergeordneten Intermediate oder beim Federation Master, wenn es keinen übergeordneten Intermediate gibt, hinterlegen. Fachdienste MÜSSEN zusätzlich die für ihre Anwendungsfälle notwendigen Scopes bzw. Claims und redirect_uris hinterlegen. Der Anbieter des Federation Master oder Intermediate MUSS vorsehen, dass die gematik in den organisatorischen Ablauf eingebunden ist und die Möglichkeit der Prüfung der vom Fachdienst eingereichten Scopes und Claims erhält. Nach Abschluss des Registrierungsprozesses MUSS der Anbieter des Federation Master oder von Intermediates den öffentlichen Schlüssel, mit dem der Federation Master (Trust Anchor) sein Entity Statement signiert (Federation Entity Signing Key), dem registrierten Teilnehmer mitteilen.

Hinweis 1: Der Registrierungsprozess muss die Registrierung der Enity-Typen openid_provider, openid_relying_party, oauth_resource und federation_entity nach [OpenID Federation 1.1 ] ("Entity Type Identifiers") unterstützen.
Hinweis 2: Der Aufbau und die Verwendung der hierarchischen Vertrauensbeziehung (Trust Chain)  ist im Standard [OpenID Federarion 1.1] festgelegt und wird darüber hinaus hier nicht weiter spezifiziert.
Hinweise 3: Die Mitteilung des öffentlichen Schlüssel des Federation Entity Signing Key muss unabhängig vom eigentlichen Entity Statement erfolgen, der Verweis auf den jwks-claim im Entity Statement ist nicht ausreichend. Bei Registrierung der Teilnehmer über den Registrierungsprozess der gematik kann die Zustellung im Rahmen dieses Prozesses erfolgen.

[<=]

A_22677-01 - Teilnehmer am Federation Master oder Intermediate löschen

Der Anbieter des Federation Master oder eines Intermadiate MUSS einen organisatorischen Prozess mit 4-Augen-Prinzip zur Erteilung von Löschaufträgen und einen technischen Prozess zum eigentlichen Löschen von Teilnehmern aus der TI-Föderation etablieren. [<=]

Hinweise 1:  Die Abwicklung kann über Service Request durch gematik. oder durch definierte Trigger im Rahmen eines Sicherheitsvorfalls erfolgen.

Hinweis 2: Beim Löschen eines sektoralen Identity Providers aus der Föderation wird zusätzlich die Sperrung der Signaturzertifikate in der Komponenten-PKI veranlasst, welche dieser zur Signatur seiner ID_TOKEN verwendet. Dies geschieht selbstständig durch den Anbieter des IDP oder bei "Wegfall der Voraussetzung für den Betrieb" durch die gematik.

4.3 Anforderungen an den Trust Anchor der TI-Föderation (Federation Master)

A_22947 - Aktualisierungszyklen für die Liste der registrierten sektoralen Identity Provider

Der Federation Master MUSS die Liste der registrierten sektoralen Identity Provider täglich aktualisieren. Darüber hinaus MUSS der Federation Master die Liste bei Neuregistrierung oder Löschung von sektoralen Identity Providern aktualisieren. [<=]

A_22609-01 - Inhalte des Federation Master Entity Statement Metadata IDP-Liste

Der Federation Master MUSS im Entity Statement zusätzlich das folgende Attribut als metadata/federation_entity angeben:

Tabelle 15: Attribut "IDP List Endpoint"

Attribut Typ Beschreibung Beispiel
idp_list_endpoint URL Adresse des Endpunktes zum Abrufen einer Liste aller sektoraler Identity Provider mit deren Namen, Logo, Identifier und Nutzergruppe "https://master0815.de/idp_list.jws"
[<=]

A_22945 - Schlüssel für Certificate Transparency TLS-Zertifikate übergeben

Der Anbieter des Federation Master MUSS einen organisatorischen Prozess etablieren, über den die Übergabe der öffentlichen Schlüssel von TLS-Zertifikaten zu Domänen eines sektoraler Identity Provider, welche in der VAU terminieren, vom Anbieter des sektoralen IDP an den Federation Master erfolgt. [<=]

Hinweis: Für den Ablauf der Schlüsselprüfungen siehe [Monitoring der TLS- Zertifikate der VAU].

A_22968 - Maßnahmen bei nicht erfolgreicher TLS-Zertifikatsprüfung durch den Federation Master

Gibt es mindestens ein TLS-Zertifikat der Domäne/Unterdomäne eines sektoralen Identity Provider, das in der VAU terminiert und dessen öffentlicher Schlüssel nicht oder falsch beim Federation Master registriert ist, so ist die Prüfung nicht erfolgreich. Für diesen Fall MUSS der Anbieter des Federation Master organisatorische und technische Prozesse mit geeigneten Maßnahmen zur Analyse und Problembeseitigung etablieren. [<=]

Hinweis: Geeignete Maßnahmen können je nach Analyseergebnis z.B. das Einstellen von Security-Bugs beim Betreiber des sektoralen Identity Provider, die Einstellung eines sicherheitsrelevanten Notfalls gegen den Anbieter des entsprechenden sektoralen IDP durch den Federation Master im ITSM, aber auch das Löschen des betroffenen sektoralen IDP sein.

A_30010 - Trust Mark Anbieter

Der Anbieter des Federation Master MUSS die Liste der verfügbaren Trust Marks und welche Superior Entities diese ausstellen dürfen, mittels eines organisatorischen Prozess auf Anforderung durch die Gematik anpassen können.
Initial umfasst diese

Trust Mark Herausgeber
https://gemspec.gematik.de/trustmarks/zeta_guard
  • <uri des Anbieters der ZETA-TI-Intermediate>
[<=]

A_29667 - Maximale Verwendungsdauer für Schlüssel von Superior Entities

Anbieter des Federation Master und von Intermediates MÜSSEN Schlüsselpaare, welche zur Signatur von Entity Statements (Federation Entity Signing Key) oder zur TLS-Authentisierung verwendet werden, nach maximal 398 Tagen austauschen. [<=]

4.3.1 TI-Trust Chain Resolver

Der TI-Trust Chain Resolver erüllt die Funktionalität zur Auflösung einer Vertrauenskette ausgehend von der Entity Configuration eines Teilnehmers bis zum TI-Trust Anchor [OpenID Federation 1.1] - "Resolve Entity". Ein Teilnehmer der TI-Föderation kann die Validierung der Trust Chain durch den TI-Trust Chain Resolver durchführen lassen und das Ergebnis der Prüfung speichern.

A_28987 - TI-Trust Chain Resolver

Der Federation Master MUSS die Funktionalität eines TI-Trust Chain Resolver gemäß [OpenID Federation 1.1] implementieren. Der Endpunkt, unter dem die Funktionalität von einem TI-Föderationsteilnehmer aufgerufen werden kann, MUSS in der Entity Configuration allen TI-Teilnehmern mit dem Entity Typ federation_entity im claim federation_resolve_endpoint angegeben werden. [<=]

4.4 ZETA TI-Intermediate

Dieses Kapitel beschreibt die Anforderungen an die Superior-Entity "ZETA TI-Intermediate".

Der ZETA TI-Intermediate, ist eine Superior-Entity, bei welcher alle ZETA-Authorization Server für TI-Fachdienste registriert sind. Die Einführung dieses Intermediate (gemäß [OpenID Federation 1.1]) wird bedingt durch Anforderungen an ZETA-Authorization Server, welche für den übrigen Teil der TI-Föderation nicht oder noch nicht gelten:

  • Das Entity Statement von ZETA-Authorization Servern wird von einer großen Anzahl ZETA-Client aufgerufen. ZETA-Clients ermitteln über das Entity Statement die Adresse der Ressource, auf die nach erfolgreicher Authentifizierung zugegriffen wird. Die ZETA-Clients sind nicht Teil der TI-Föderation. Zur Herstellung des Vertrauensverhältnisses zwischen ZETA-Client und einem ZETA-Authorization Server muss jeder ZETA-Authorization Server in seinem Entity Statement eine Trust Mark [OpenID Federation 1.1 Kapitel "Trust Marks"] ausgestellt und signiert von einer Superior Entity enthalten. Ein beliebiger ZETA-Client kann die Trust Mark validieren.
  • Die Umstellung von TI-Fachdiensten auf ZETA hat zur Folge, dass temporär sowohl die herkömmlichen Fachdienst Authorization Server als auch die Fachdienst ZETA-Authorization Server für einen Fachdienst in der TI-Föderation registriert sind. Es ist sicherzustellen, dass Clients den richtigen Authorization Server eines Fachdienstes zur Authentifizierung aufrufen.

Der ZETA TI-Intermediate kann sowohl Trust Marks ausstellen, als auch das Auffinden der richtigen Authorization Server erleichtern. Der ZETA-TI-Authorization Server Intermediate ist Subordinate-Entity des Federation Master.

Abbildung 4 : ZETA TI-Intermediate in der TI-Föderation

A_28985 - Ausstellen einer Trust Mark als Nachweis der Teilnehmer-Registrierung

Der Anbieter der ZETA-TI-Authorization Server Intermediate MUSS für jeden bei ihm registrierten Teilnehmer eine Trust Mark gemäß [OpenID Federation 1.1] -"Trust Marks" mit dem trust_mark_type Wert https://gemspec.gematik.de/trustmarks/zeta_guard ausstellen und für deren Gültigkeitszeitraum im System vorhalten.
Die ausgestellte Trust Mark DARF NICHT länger als 30 Tage nach Ausstellungszeitpunkt und nicht über das maximale Alter des Signaturschlüssels (A_29667) hinaus gültig sein. Der Anbieter der Intermediate MUSS spätestens 14 Tage vor Ablauf einer nicht widerrufenden Trust Mark eine neue Trust Mark nach diesen Vorgaben ausstellen (ohne die bisherige zu widerrufen).
[<=]

A_28986 - Teilnehmer-Registrierung ausschließlich ZETA-TI-Authorization Server

Der Anbieter des ZETA-TI-Authorization Server Intermediate MUSS sicherstellen, dass auschließlich ZETA-TI-Authorization Server als Subordinate Entities am ZETA-TI-Authorization Server Intermediate registriert werden. [<=]

A_30006 - Trust Mark Download Endpunkt

Der ZETA-TI-Authorization-Server Intremediate MUSS am federation_trust_mark_endpoint den Abruf der mit dem Parameter trust_mark_type zur sub gehörigen Entity gemäß [OpenID Federation 1.1] ohne Authentisierung zum Download anbieten. [<=]

A_30007 - Trust Mark Ausgabe

Die ZETA-TI-Authorization Server Intermediate MUSS bei Ausgabe (Resolve, Download) einer Trust Mark, für die systemintern mehrere zeitlich überlappende, gültige Trust Marks vom gleichen trust_mark_type vorhanden sind, stets die jüngste ausgeben. [<=]

4.5 Allgemeine Sicherheitsanforderungen

A_22678-01 - Schützenswerte Objekte

Anbieter des Federation Master oder von Intermediates MÜSSEN die folgenden kryptographischen Objekte als schützenswerte Objekte in seinem Sicherheitskonzept berücksichtigen:

  • Privater Schlüssel und öffentlicher Schlüssel des Federation Master oder Intermediate
  • Öffentliche Schlüssel von registrierten Clients
  • Authentisierungsinformationen von Löschberechtigten
  • Dokumentation über beauftragte und durchgeführte Löschungen
  • Statusinformationen
  • Authentisierungsinformationen zur Authentisierung von internen Akteuren bzw. Rollen
  • Protokolldaten
  • Konfigurationsdaten
[<=]

A_22601-01 - Berücksichtigung OWASP-Top-10-Risiken

Anbieter des Federation Master oder von Intermediates MÜSSEN Maßnahmen zum Schutz sowohl vor den zum Zulassungszeitpunkt aktuellen OWASP-Top-10-Risiken umsetzen, als auch die nach dem Zulassungszeitpunkt jeweils aktuellen OWASP-Top-10-Risiken berücksichtigen. [<=]

4.6 Sicherheit der Netzübergänge

A_22591-01 - Sicherung zum Transportnetz Internet durch Paketfilter

Anbieter des Federation Master oder von Intermediates MÜSSEN dafür sorgen, dass das Transportnetz Internet durch einen Paketfilter (ACL) gesichert wird und ausschließlich die erforderlichen Protokolle weiterleitet. Der Anbieter des Federation Master MUSS dafür sorgen, dass der Paketfilter des Federation Master frei konfigurierbar auf der Grundlage von Informationen aus OSI-Layer 3 und 4 ist (Quell- und Zieladresse, IP-Protokoll sowie Quell- und Zielport). [<=]

A_22592-01 - Platzierung des Paketfilters Internet

Anbieter des Federation Master oder von Intermediates DÜRFEN den Paketfilter des Federation Master zum Schutz in Richtung Transportnetz Internet  NICHT physisch auf dem vorgeschalteten TLS-terminierenden Load Balancer implementieren. [<=]

A_22593-01 - Richtlinien für den Paketfilter zum Internet

Anbieter des Federation Master oder von Intermediates MÜSSEN beim Paketfilter die Weiterleitung von IP-Paketen an der Schnittstelle zum Internet auf das HTTPS-Protokoll beschränken. [<=]

A_22594-01 - Verhalten bei Vollauslastung

Anbieter des Federation Master oder von Intermediates MÜSSEN den Paketfilter des Federation Master so konfigurieren, dass bei Vollauslastung der Systemressourcen im Federation Master keine weiteren Verbindungen angenommen werden. [<=]

Hinweis: Durch die Zurückweisung von Verbindungen wird sichergestellt, dass Clients einen Verbindungsaufbau mit einer anderen Instanz des Fachdienstes versuchen, bei dem die erforderlichen Ressourcen zur Verfügung stehen.

A_22589-01 - Richtlinien zum TLS-Verbindungsaufbau

Anbieter des Federation Master oder von Intermediates MÜSSEN dafür sorgen, dass der Eingangspunkt des Federation Master oder Intermediate sich beim TLS-Verbindungsaufbau über das Transportnetz gegenüber dem Client mit einem TLS-Zertifikat eines Herausgebers gemäß [CAB-Forum] authentisiert.
Anbieter des Federation Master oder von Intermediates MÜSSEN die TLS-Zertifikate aus einer CA beziehen, welche Certificate Transparency gemäß RFC 6962 / RFC 9162 unterstützt und täglich prüfen und sicherstellen, dass für seine Domänen keine unbekannten Zertifikate im Certificate Transparency Log gelistet werden.
Anbieter des Federation Master oder von Intermediates MÜSSEN für seine TLS-Zertifikate Certification Authority Authorization (CAA) DNS Resource Records nach RFC 6844 bereitstellen, welche die Validität der ausstellenden CA verifizieren. [<=]

4.7 Fehlermeldungen

A_22595-01 - Format der Fehlermeldungen

Federation Master und Intermediate MÜSSEN für die verschiedenen Teilfunktionen geeignete Fehlermeldungen erzeugen und diese an den jeweiligen Aufrufer übergeben. Die Festlegungen im Standard [OpenID Federation 1.1] MÜSSEN bei der Definition der Meldungsinhalte berücksichtigt werden. [<=]

A_22596-01 - Nutzung von eindeutigen Error-Codes bei der Erstellung von Fehlermeldungen

Federation Master und Intermediate MÜSSEN Fehler durch eine eindeutige Nummer erkennbar machen und der gematik eine Liste der Error-Codes zur Verfügung stellen, damit die Ursachenklärung vereinfacht möglich wird. Die Festlegungen im Standard [OpenID Federation 1.1] MÜSSEN bei der Definition der Fehlercodes berücksichtigt werden. [<=]

A_22597-01 - Verwendung eines einheitlichen Schemas für die Aufbereitung von Fehlermeldungen

Federation Master und Intermediate MÜSSEN alle ausgeworfenen Fehlermeldungen zur Weiterverarbeitung in einem einheitlichen Schema aufbereiten und bereitstellen. Zeitstempel MÜSSEN auf der UTC basieren. [<=]

A_22598-01 - Formulierung der Fehlermeldungen

Federation Master und Intermediate MÜSSEN Fehlermeldungen, welche dem Nutzer angezeigt werden, in der Art ausformulieren, dass es dem Nutzer möglich ist, eigenes Fehlverhalten anhand der Fehlermeldung abzustellen. [<=]

A_22599-01 - Nutzung einer eindeutigen Beschreibung beim Aufbau von Fehlermeldungen

Federation Master und Intermediate MÜSSEN jedem Fehler eine eindeutige eigene Beschreibung zukommen lassen, sodass eine Fehlermeldung nicht für unterschiedliche Fehlerursachen zur Anwendung kommt. [<=]

A_22600-01 - Ausgabe der Fehlermeldungen in umgekehrter Reihenfolge des Auftretens

Federation Master und Intermediate MÜSSEN aufeinander aufbauende Fehlermeldungen in der umgekehrten Reihenfolge ihres Auftretens "Traceback (most recent call last)" ausgeben. [<=]

5 Anhang – Verzeichnisse

5.1 Abkürzungen

Tabelle 16: Abkürzungen

Kürzel
Erläuterung
CT Certificate Transparency
JWE JSON Web Encryption
JWK JSON Web Key
JWS  JSON Web Signature
JWT JSON Web Token
OIDC OpenID Connect
OP OpenID Provider
OSI Open Systems Interconnection model
RP Relying Party
TLS Transport Layer Security
URL Uniform Resource Locator

5.2 Glossar

Tabelle 17: Glossar

Begriff
Erläuterung
Anwendungsfrontend Die Applikation durch welche ein Nutzer die Dienste einer Anwendung der Telematikinfrastruktur wie etwa das E-Rezept nutzt.
Authentifizierung Prüfung eines Identitätsnachweis des Nutzers am Gerät mit bestimmten Authentifizierungsmittel.
Consent Zustimmung des Nutzers zur Verarbeitung der angezeigten Daten. Der Consent umfasst die Attribute, welche vom sektoralen Identity Provider bezogen, auf die im Claim des jeweiligen Fachdienstes eingeforderten Attribute zusammenfasst. Es besteht Einigkeit zwischen dem, was gefordert wird, und welche Attribute im Token bestätigt werden.
DiGA Digitale Gesundheitsanwendung(en)
Fachanwendungen / Relying Party Fachanwendungen sind Relying Party (RP) im Kontext der OIDC-Spezifikation. Nach erfolgreicher Authentifizierung des Nutzers und dessen Zustimmung zur Datennutzung (Consent Freigabe) bekommt die Fachanwendung Zugang zu einem definierten Teil der Identifikationsattribute des Nutzers. Die Fachanwendung nutzt diese Informationen zur Autorisierung des Nutzers zu der Durchführung definierter Anwendungsfälle der Fachanwendung.
Federation Master Der Federation Master basiert auf den Standards OpenID Connect (OIDC), Open Authorization 2.0 (OAuth 2) und JSON Web Token (JWT). Der Federation Master ist einerseits der Trust Anchor des Vertrauensbereichs der Föderation. Andererseits stellt der Federation Master Schnittstellen bereit, welche Auskunft, über die in der Föderation registrierten, sektoralen Identity Provider gibt.
Identitätsattribute Daten, welche eine natürliche Person eindeutig identifizieren (Name, Vorname, Geburtsdatum, Anschrift, KVNR).
identitätsbestätigenden Institutionen Institutionen, welche die Identität einer natürlichen Person geprüft haben und bestätigen können. Solche Institutionen sind beispielsweise die Krankenkassen, welche die Identität der bei ihnen versicherten Personen bestätigen können.
Nutzergruppen Nutzergruppen sind Personengruppen mit bestimmten Rollen im Kontext der TI-Anwendungslandschaft. Nutzergruppen sind beispielsweise Versicherte und Leistungserbringer (ggf. weiter differenziert - Ärzte, Zahnärzte, etc.).
sektoraler Identity Provider Als sektoraler IDP wird ein Dienst bezeichnet, welcher nach vorheriger Authentifizierung Identitätsinformationen für eine spezifische Nutzergruppe innerhalb der TI des Gesundheitswesens bereitstellt, welche anschließend verwendet werden, um auf verschiedene Fachdienste und deren Fachdaten und -prozesse zuzugreifen. 

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

5.3 Abbildungsverzeichnis

5.4 Tabellenverzeichnis

5.5 Referenzierte Dokumente

5.5.1 Dokumente der gematik

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

Tabelle 18: Quellen

[Quelle]
Herausgeber: Titel
[gemGlossar] gematik: Einführung der Gesundheitskarte – Glossar
[gemSpec_Krypt] gematik: Übergreifende Spezifikation zur Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur
[gemSpec_PKI] gematik: Übergreifende Spezifikation  PKI
[gemSpec_IDP_Sek] gematik: Spezifikation der sektoralen Identity Provider der TI-Föderation
[gemSpec_IDP_Frontend] gematik: Spezifikation der Frontendkomponenten von Fachdiensten in der TI-Föderation
[gemSpec_IDP_FD] gematik: Spezifikation der Fachdienste in der TI-Föderation

5.5.2 Weitere Dokumente

Tabelle 19: Weitere Dokumente

[Quelle]
Herausgeber (Erscheinungsdatum): Titel
JWT [RFC7519] JSON Web Token (JWT) (Mai 2015)
https://datatracker.ietf.org/doc/html/rfc7519 
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels
https://datatracker.ietf.org/doc/html/rfc2119 
[RFC9126]  OAuth 2.0 Pushed Authorization Requests
https://datatracker.ietf.org/doc/html/rfc9126 
[RFC6749] Roles
https://datatracker.ietf.org/doc/html/rfc6749#section-1.1 
[RFC7636] Proof Key for Code Exchange by OAuth Public Clients
https://datatracker.ietf.org/doc/html/rfc7636 
OAuth 2.0 Spezifikation ([RFC6749]) The OAuth 2.0 Authorization Framework (Oktober 2012)
https://datatracker.ietf.org/doc/html/rfc6749 
[OpenID Connect Core 1.0] OpenID Connect Core 1.0 (OpenID Connect Core 1.0 incorporating errata set 2)
https://openid.net/specs/openid-connect-core-1_0.html 
[OpenID Connect Basic Client Implementer's Guide 1.0] OpenID Connect Basic Client Implementer's Guide 1.0 (draft 40, Juli 2020)
https://openid.net/specs/openid-connect-basic-1_0.html
[OpenID Connect Registration 1.0] OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2 (15. Dezember 2023)
https://openid.net/specs/openid-connect-registration-1_0.html 
[OpenID Federation 1.1] OpenID Federation1.0 (5. Mai 2026)
https://openid.net/specs/openid-federation-1_1.html  
[Pushed Authorization Request] OAuth 2.0 Pushed Authorization Requests (September 2021)
https://datatracker.ietf.org/doc/html/rfc9126 
PKCE ([RFC7636]) Proof Key for Code Exchange by OAuth Public Clients (September 2015)
https://datatracker.ietf.org/doc/html/rfc7636 
CAB-Forum https://cabforum.org/ 
OWASP Open Web Application Security Project
https://owasp.org/ 
Certificate Transparency (CT) Certificate Transparency Version 2.0 (Dezember 2021)
https://datatracker.ietf.org/doc/html/rfc9162