A_22838 - Entgegennahme von Sperrmeldungen

Der Anbieter des sektoralen IDP MUSS Sperrmeldungen von Sperrberechtigten, zu von ihm verantworteten Authentisierungsmitteln, jederzeit entgegennehmen und das betroffene Authentisierungsmittel oder auch den gesamten Zugang des Nutzers daraufhin unverzüglich sperren. [<=]

A_22690 - Darstellen der Voraussetzungen für sicheren Betrieb des Produkts im Betriebshandbuch

Der Hersteller des sektoralen IDP MUSS für sein Produkt im dazugehörigen Betriebshandbuch leicht ersichtlich darstellen, welche Voraussetzungen vom Betreiber und der Betriebsumgebung erfüllt werden müssen, damit ein sicherer Betrieb des Produktes gewährleistet werden kann. [<=]

A_22691 - Sicherer Betrieb des Produkts nach Betriebshandbuch

Der Anbieter eines sektoralen IDP MUSS die im Betriebshandbuch des eingesetzten sektoralen IDP beschriebenen Voraussetzungen für den sicheren Betrieb des Produktes gewährleisten. [<=]

A_23044 - Unterstützung von Diensten außerhalb der TI

Der Anbieter des sektoralen IDP KANN die Anmeldung an weiteren Diensten außerhalb der Föderation unterstützen und diesen die Authentisierung von Nutzern auf Basis der bestehenden digitalen Identitäten anbieten. [<=]

A_23337-01 - Mindestvorgaben für Schlüssel von sektoralen IDPs als Teilnehmer der TI-Föderation

Ein sektoraler IDP als Teilnehmer der TI-Föderation MUSS bei dem eingesetzten Schlüsselmaterial (Signatur,  mTLS Clientzertifikat, Entity Statement, etc.), folgende Vorgaben umsetzen:

1. Alle verwendeten Schlüssel MÜSSEN ein Sicherheitsniveau von 120 Bit ermöglichen (vgl. [gemSpec_Krypt#5 "Migration 120-Bit Sicherheitsniveau"]).
2. Alle ECC-Schlüssel MÜSSEN auf einem folgenden der Domainparameter (Kurven) basieren:
1. P-256 oder P-384 [FIPS-186-4]

A_22239 - Schützenswerte Objekte

Der Anbieter eines sektoralen Identity Provider MUSS die folgenden kryptographischen Objekte als schützenswerte Objekte in seinem Sicherheitskonzept berücksichtigen: (a) Private Schlüssel, (b) Öffentlicher Schlüssel, (c) Öffentliche Schlüssel von registrierten Clients, (d) Datensätze zu den einzelnen Nutzern, (e) Authentisierungsinformationen von Sperrberechtigten, (f) Dokumentation über beauftragte und durchgeführte Sperrungen, (g) Statusinformationen, (h) Authentisierungsinformationen zur Authentisierung von internen Akteuren bzw. Rollen, (i) Protokolldaten, (j) Konfigurationsdaten. [<=]

A_22240 - Berücksichtigung OWASP-Top-10-Risiken

Der Anbieter des sektoralen Identity Provider MUSS Maßnahmen zum Schutz vor den zum Zulassungszeitpunkt aktuellen OWASP-Top-10-Risiken umsetzen und dokumentieren, wie es vorgesehen ist, ebenfalls auf die nach dem Zulassungszeitpunkt aktuellen OWASP-Top-10-Risiken zu reagieren. [<=]

A_22241 - Interner Datenaustausch der Komponenten des sektoralen Identity Provider

Der Anbieter eines sektoralen Identity Provider MUSS beim internen Datenaustausch die Integrität, Authentizität und Vertraulichkeit der Daten sichern. [<=]

A_22242-01 - Gesicherte externe Schnittstellen des sektoralen Identity Provider

Der Anbieter eines sektoralen Identity Provider MUSS für den Datenaustausch mit anderen Rollen und Diensten Mechanismen zur Sicherung der Datenintegrität, der Authentizität und der Vertraulichkeit der Daten zur Verfügung stellen. Hierzu gehören z. B. die Schnittstellen vom Anbieter eines sektoralen Identity Provider zur Attributbestätigenden Stelle für die Übermittlung der Attribute bei der Einrichtung eines Nutzers sowie von Supportfälle.
[<=]

A_22243-02 - Nutzung bestehender Datensätze bei Registrierung für Endanwender (Versicherte)

Der Anbieter des sektorale Identity Provider SOLL für die Registrierung der Endanwender die bestehenden Datensätze der Endanwender (Versicherte) beim Kostenträger verwenden, so wie sie für eine Identifikation nach [GKV-SV Richtlinie "Kontakt mit Versicherten] beschrieben wurden. [<=]

A_22244 - Trennung der Betriebsumgebungen

Der Anbieter eines sektoralen Identity Provider MUSS sicherstellen, dass das Testsystem von dem Produktivsystem technisch, organisatorisch und betrieblich so getrennt wird, dass keine gegenseitige Beeinflussung und keine Verwechslung möglich sind.  [<=]

A_22245 - Datenschutzgerechte Einrichtungs- und Sperrprozesse

Der Anbieter eines sektoralen Identity Provider MUSS die Einrichtungs- und Sperrprozesse datenschutzgerecht ausgestalten, d.h. insbesondere sind für die Verarbeitung der Antrags- und Sperrauftragsdaten die Datenschutzgrundsätze gemäß Art. 5 DSGVO zu berücksichtigen, sowie die technischen und organisatorischen Maßnahmen nach Art. 25 und Art. 32 DSGVO zu treffen. [<=]

A_22246 - Löschung von Nutzerinformationen

Der Anbieter eines sektoralen Identity Provider MUSS die Attributsdaten und Sperraufträge zu einem Nutzer unverzüglich löschen, sobald die gesetzlichen oder vertraglichen Aufbewahrungsfristen erreicht sind. [<=]

A_22839 - Fehlerprotokollierung

Falls der Anbieter eines sektoralen IDP eine Protokollierung zum Zwecke der Fehler- bzw. Störungsbehebung durchführen muss, MÜSSEN die Protokolldaten entsprechend dem Datenschutzgrundsatz der Datenminimierung (gemäß Art. 5 Abs. 1 Satz 1 lit.c DSGVO unter Berücksichtigung der Art. 25, 32 DSGVO) derart gestaltet sein, dass nur personenbezogene Daten in der Art und dem Umfang enthalten sind, wie sie zur Behebung erforderlich sind. Insbesondere MUSS der Anbieter eines sektoralen IDP sicherstellen, dass ein Bezug zwischen Nutzer und Fachdienst aus den Protokollen nicht ersichtlich sein. [<=]

A_23021 - Trennung von Diensten der Föderation und weiteren unterstützten Anwendungen

Wenn der Anbieter eines sektoralen Identity Providers die Anmeldung an weiteren Dienste außerhalb der Föderation unterstützt, MUSS sichergestellt sein, dass die Anforderungen an Verfügbarkeit, Performance und Sicherheit der Schnittstellen für Fachdienste der Föderation erfüllt werden. [<=]

A_23023 - Sicherung externen Schnittstellen gegen bösartige Eingaben

Der sektorale IDP MUSS sicherstellen, dass alle Eingabewerte, welche vom sektoralen IDP über externe Schnittstellen (siehe Tabelle "Schnittstellenübersicht") entgegengenommen und verarbeitet werden, auf schadhafte Werte geprüft werden.
[<=]

A_23022 - Prozesse zum Ändern oder Löschen von Daten der Authentisierungsprozesse

Werden Daten der Authentisierungsprozesse im sektoralen IDP ohne direkte Beteiligung des Nutzers geändert oder gelöscht, MUSS der Anbieter des sektoralen IDP sicherstellen, dass die operativen Prozesse hierfür ausschließlich im 4-Augen-Prinzip durchgeführt werden. Der Nutzer MUSS über die Änderungen informiert werden und die Änderung MUSS erkennbar sein.
[<=]

A_23499 - Prozesse zum Ändern oder Löschen von personenbezogenen Daten

Werden personenbezogene Daten im sektoralen IDP geändert oder gelöscht, ohne dass der Betroffene direkt involviert ist, so MUSS der Anbieter des sektoralen IDP sicherstellen, dass die operativen Prozesse dazu ausschließlich im 4-Augen-Prinzip ausgeführt werden. Der Nutzer ist über die Änderungen zu informieren. Personenbezogene Daten, die über den Synchronisationsprozess mit den Kassensystemen geändert oder gelöscht werden, sind von diesem operativen Prozess nicht betroffen. [<=]

A_22824 - Verhalten bei Vollauslastung

Der Anbieter eines sektoralen Identity Provider MUSS den Dienst so konfigurieren, dass bei Vollauslastung der Systemressourcen im sektoralen Identity Provider keine weiteren Verbindungen angenommen werden und dieser stattdessen mit dem HTTP-Statuscode "429 - Too Many Requests" antwortet. [<=]

A_22692 - Kriterien für die Standortwahl von Rechenzentren

Der Anbieter des sektoralen IDP MUSS nachweisen, dass er die aktuellen Empfehlungen des BSI bei der Standortwahl seiner Rechenzentren vollumfänglich umsetzt. Der Anbieter des sektoralen IDP MUSS Unterschreitungen der Empfehlungen des BSI begründen und die Abmilderung der Risiken begründet nachweisen. Der Anbieter des sektoralen IDP MUSS einen Prozess für die Umsetzung zukünftige Empfehlungen des BSI bei der Standortwahl seiner Rechenzentren nachweisen. [<=]

A_22250 - Schutz der Verbindung zum sektoralen Identity Provider

Der Anbieter eines sektoralen Identity Provider MUSS sicherstellen, dass die Schnittstellen des sektoralen Identity Provider nur über eine gegen Abhören, Manipulation und Replay-Angriffe geschützte Verbindung genutzt werden können. [<=]

A_22512 - Schutz der Schnittstellen des sektoralen Identity Provider ins Internet

Der Anbieter eines sektoralen IDP MUSS sicherstellen, dass seine Schnittstellen ins Internet an allen Standorten durch einen DDoS-mitigierenden Dienstleister geschützt werden. [<=]

A_23099 - Datenverarbeitung innerhalb der Europäischen Union

Der Anbieter eines sektoralen IDP MUSS im Sinne der vollständigen DSGVO-Konformität sicherstellen, dass die Datenverarbeitung innerhalb der Europäischen Union erfolgt und dieses auch nachweisen. [<=]

A_22694 - Georedundanz des sektoralen Identity Provider

Der Anbieter des sektoralen Identity Provider MUSS diesen an mindestens zwei Standorten betreiben.
Jeder Standort MUSS dabei die Performancevorgaben allein erfüllen.
Eine getrennte Adressierung durch zugreifende Anwendungsfrontends und Fachdiensten MUSS hierdurch möglich sein - alternativ ist diese Adressierung auch durch den DDoS-mitigierenden Dienstleister erlaubt.
[<=]

A_22695 - Mindestabstand für Georedundanz des sektoralen Identity Provider

Ab dem 31.12.2023 MUSS der Anbieter des sektoralen Identity Provider seinen Dienst an zwei Standorten gemäß A_22692 betreiben, wobei eine Unterschreitung des Abstandes von 100 km gemäß A_22692 nicht zulässig ist. [<=]

A_22506-01 - Unabhängiges Bedienpersonal pro Standort des sektoralen Identity Provider

Der Anbieter des sektoralen Identity Provider MUSS pro Standort ein unabhängiges Bedienpersonal vorhalten, um die Risiken der Standortvorgaben des BSI tragen zu können. [<=]

A_22508 - Ausschluss von nicht erlaubten Authenticator-Modul Versionen (Rohdatenerfassung v.02)

Der sektorale Identity Provider MUSS von ihm nicht erlaubte Authenticator-Module (anhand der Versionsnummern) ablehnen, von einer Kommunikation mit dem sektoralen Identity Provider ausschließen und diesen Verbindungsversuch mit dem Status-Code 79105 in den Rohdaten protokollieren. [<=]

A_22509 - Ausschluss bei fehlenden Authenticator-Modul Versionsnummern (Rohdatenerfassung v.02)

Der sektorale Identity Provider MUSS Authenticator-Module mit fehlenden Versionsnummern ablehnen, von einer Kommunikation mit dem sektoralen Identity Provider ausschließen und diesen Verbindungsversuch in den Rohdaten mit dem Error-Code 403 protokollieren. [<=]

A_22931 - Zu verwendende Produktversion in der Kommunikation zum IDP

Das Authenticator-Modul MUSS in Requests an den IDP seine Produktversion übermitteln. [<=]

A_22253 - Ausschluss bestimmter Authenticator-Modul Versionen von der Kommunikation

Der sektorale Identity Provider MUSS die vom Authenticator-Modul mitgeteilte Versionsnummer erkennen und festgelegte Versionsnummern über eine blockinglist von einer Kommunikation ausschließen können. [<=]

A_22254-01 - Ausschluss von Authenticator-Modul Versionen (Rohdatenerfassung v.02)

Der sektorale Identity Provider MUSS auf Anweisung der gematik Authenticator-Module mit bestimmten Versionsnummern von einer Kommunikation mit dem sektoralen Identity Provider ausschließen und diesen Verbindungsversuch in den Rohdaten protokollieren. [<=]

A_23192 - Maximale Verwendungsdauer für Schlüssel

Der Anbieter des sektoralen Identity Provider MUSS Schlüsselpaare welche zur Signatur von Entity Statements bzw. ID Token oder zur TLS-Authentisierung verwendet werden, nach maximal 398 Tagen austauschen. [<=]

A_22864 - Umsetzung von Operationen in einer Vertrauenswürdigen Ausführungsumgebung (VAU)

Der sektorale IDP MUSS die Verarbeitung aller Operationen welche die Ziele gemäß [A_23018], [A_23019] und [A_22959] gewährleisten in einer Vertrauenswürdigen Ausführungsumgebung umsetzen. Die HTTP-Verbindungen zwischen Fachdiensten und sektoralem IDP MÜSSEN als mTLS-Verbindungen ausgelegt werden, welche innerhalb der VAU terminieren. [<=]

A_23002 - sicherer Betrieb der Vertrauenswürdigen Ausführungsumgebung (VAU)

Der Anbieter des sektoralen IDP MUSS sicherstellen, dass alle Operationen, welche die Ziele gemäß A_23018, A_23019 und A_22959 gewährleisten, in einer vertrauenswürdigen Ausführungsumgebung umgesetzt werden. [<=]

A_23018 - Anforderungen an den Schutz vor Profilbildung

A_23019 - Anforderungen an den Schutz der Operationen in einer Vertrauenswürdigen Ausführungsumgebung (VAU)

• Sowohl Dritte als auch der Betreiber selbst DARF NICHT Zugriff auf das Schlüsselmaterial der TLS-Verbindungen haben.
  
• Sowohl Dritte als auch der Betreiber selbst DARF NICHT Zugriff auf die für die Signatur von ID Token verwendeten Schlüssel haben.
  
• Sowohl Dritte als auch der Betreiber selbst DARF NICHT Zugriff auf die im AUTHORIZATION_CODE und in der Request-URI kodierten Informationen haben.
  

A_22959 - Prozess zur Consent-Freigabe durch den Nutzer

Der Anbieter des sektoralen IDP MUSS dafür sorgen, dass der Prozess zur Freigabe des Consent durch den Nutzer verschlüsselt und nicht einsehbar für Dritte oder den Betreiber selbst erfolgt. [<=]

A_22829-01 - Anbieter sektoraler IDP Speicherung Schlüsselmaterial in HSM

Der Anbieter des sektoralen IDP MUSS das private Schlüsselmaterial für kryptografische Verfahren in einem HSM speichern, dessen Eignung durch eine erfolgreiche Evaluierung nachgewiesen wurde. Als Evaluierungsschemata kommen dabei Common Criteria oder Federal Information Processing Standard (FIPS) in Frage.
Die Prüftiefe MUSS mindestens: 

1. FIPS 140-2 Level 3 oder
2. FIPS 140-3 Level 3 oder
3. Common Criteria EAL 4+ erweitert um AVA_VAN.5
   

A_23205 - Prozesse für die Verwaltung des HSM

Der Anbieter des sektoralen IDP MUSS Prozesse für die Verwaltung der Systeme der VAU etablieren, welche die Authentizität und Integrität der Verarbeitungskontexte systematisch von einem kryptographischen Root-of-Trust ableiten, der in einem HSM gemäß A_22829 verwaltet wird.
Der Anbieter des sektoralen IDP MUSS bei der Ableitung ein Vertrauensniveau erreichen, welches für den Schutzbedarf der in der VAU verarbeiteten Daten angemessenen ist und das auf Attestation der genutzten Systeme sowie ggf. auf der Prüfung von Signaturen der geladenen Software inklusive ihrer Konfiguration basiert.
Der Anbieter des sektoralen IDP MUSS für die Verwaltung des Root-of-Trust ein Mehraugenprinzip umsetzen und - soweit für systematischen Ausschluss einseitig durch den Anbieter durchführbarer Manipulationen erforderlich - eine Einbeziehung der gematik vorsehen.
Der Anbieter des sektoralen IDP MUSS der gematik dabei eine Remote-Teilnahme an den erforderlichen Zeremonien ermöglichen.  [<=]

A_22830 - sektoraler IDP – Verarbeitungskontext der VAU

Der Verarbeitungskontext des sektoralen IDP MUSS sämtliche physikalischen Systemkomponenten sowie sämtliche Softwarekomponenten umfassen, deren Sicherheitseigenschaften sich auf den Schutz der personenbezogenen Daten vor Zugriff durch Unbefugte bei ihrer Verarbeitung im Klartext auswirken können. [<=]

A_22840 - Verschlüsselung von außerhalb des Verarbeitungskontextes der VAU gespeicherten Daten

Der Verarbeitungskontext des sektoralen IDP MUSS sicherstellen, dass sämtliche schützenswerten Daten vor einer Speicherung außerhalb der VAU verschlüsselt werden. Dies betrifft auch Daten zu Logging und Protokollierung. [<=]

A_22841 - Schutz der Persistenzschlüssel durch ein HSM

Schlüsselmaterial, dass zur Verschlüsselung von außerhalb des Verarbeitungskontextes der VAU gespeicherten Daten genutzt wird, MUSS entweder durch ein HSM geschützt in den Verarbeitungskontext der VAU eingebracht werden, oder in einem HSM verbleiben. [<=]

A_22842 - Bereitstellung Persistenzschlüssel

Das HSM der VAU des sektoralen IDP MUSS eine Schnittstelle zum Abruf symmetrischer Persistenzschlüssel bereitstellen. Erzeugte Schlüssel für die Persistierung der Daten MÜSSEN eineindeutig einem Nutzer zugeordnet sein. [<=]

A_22843 - Geschützte Weitergabe von Daten an autorisierte Nutzer durch die VAU

Der Verarbeitungskontext des sektoralen IDP MUSS sicherstellen, dass sämtliche schützenswerten Daten ausschließlich über TLS-gesicherte Verbindungen weitergegeben werden. [<=]

A_22844 - Transportverschlüsselte Übertragung von Daten mit Fachdiensten

Der Verarbeitungskontext des sektoralen IDP MUSS sicherstellen, dass er nur mTLS-gesichert mit Fachdiensten kommuniziert. [<=]

A_22847 - Authentisierung gegenüber Clients

Der Verarbeitungskontext des sektoralen IDP MUSS sich gegenüber Clients, welche mit ihm kommunizieren, mit einem TLS-Zertifikat ausweisen, auf dessen privaten Schlüssel der Betreiber des sektoralen IDP keinen Zugriff hat. [<=]

A_23006 - Subdomäne für Webservice-Endpunkte in der VAU

Der Verarbeitungskontext des sektoralen IDP MUSS diese Endpunkte anbieten:

• Endpunkt für Authorization Requests
• Endpunkt für Pushed Authorization Requests
• Token-Endpunkt

A_22943 - Richtlinien zum TLS-Verbindungsaufbau

Der Anbieter des sektoralen IDP MUSS dafür sorgen, dass der Verarbeitungskontext des sektoralen IDP sich beim TLS-Verbindungsaufbau über das Transportnetz gegenüber dem Client mit einem TLS-Zertifikat eines Herausgebers gemäß [CAB-Forum] authentisiert. Der Anbieter MUSS dafür sorgen, dass Clientsysteme beim TLS-Verbindungsaufbau eine vereinfachte Zertifikatsprüfung mit TLS-Standardbibliotheken durchführen können.  [<=]

A_22980 - Grundlage zur Prüfung der TLS-Zertifikate mittels Certificate Transparency

Der Anbieter des sektoralen IDP MUSS die TLS-Zertifikate, welche in seinem Verarbeitungskontext terminieren, aus einer CA beziehen, welche Certificate Transparency gemäß RFC 6962 / RFC 9162 unterstützt und täglich prüfen und sicherstellen, dass für die zur Verbindungen in den Verarbeitungskontext der VAU vorgesehen Domänen keine unbekannten Zertifikate im Certificate Transparency Log gelistet werden. Im Fehlerfall MUSS ein "Security Incident" (gemäß 3.4 gemRL_Betr_TI) erstellt werden.  [<=]

A_22981 - Grundlage zur Prüfung der TLS-Zertifikate mittels Certification Authority Authorization (CAA) Records

Der Anbieter des sektoralen IDP MUSS für die TLS-Zertifikate welche in seinem Verarbeitungskontext terminieren Certification Authority Authorization (CAA) DNS Resource Records nach RFC 6844 bereitstellen, welche die Validität der ausstellenden CA verifizieren.  [<=]

A_22982 - Bereitstellung der öffentlichen Schlüssel der TLS-Zertifikate

Der Anbieter des sektoralen IDP MUSS die öffentlichen Schlüssel der TLS-Zertifikate, welche in seinem Verarbeitungskontext terminieren, dem Federation Master bereitstellen. Der organisatorische Prozess zur Schlüsselübergabe ist in [gemSpec_IDP_FedMaster] beschrieben. [<=]

A_22848 - Isolation zwischen Datenverarbeitungsprozessen mehrerer Verarbeitungskontexte der VAU

Die VAU des sektoralen IDP MUSS die in ihr ablaufenden Verarbeitungen für die Daten eines Verarbeitungskontextes von den Verarbeitungen für die Daten anderer Verarbeitungskontexte in solcher Weise trennen, dass mit technischen Mitteln ausgeschlossen wird, dass die Verarbeitungen eines Verarbeitungskontextes schadhaft auf die Verarbeitung eines anderen Verarbeitungskontextes einwirken können. Die VAU des sektoralen IDP MUSS dabei insbesondere verhindern, dass die Verarbeitungen von Daten innerhalb eines Verarbeitungskontextes zu fehlerhaften Ausstellungen von Identitätsbestätigungen bei einem Authentifizierungsvorgang in einem anderen Verarbeitungskontext führen könnte. [<=]

A_22849 - Isolation der VAU von Datenverarbeitungsprozessen des Anbieters

Die VAU des sektoralen IDP MUSS die in ihren Verarbeitungskontexten ablaufenden Datenverarbeitungsprozesse von allen sonstigen Datenverarbeitungsprozessen des Anbieters trennen und damit gewährleisten, dass sowohl Dritte als auch der Betreiber des sektoralen IDP selbst vom Zugriff auf die in der VAU verarbeiteten schützenswerten Daten ausgeschlossen ist.
[<=]

A_22850 - Ausschluss von Manipulationen an der Software der VAU

Die VAU des sektoralen IDP MUSS eine Manipulation der eingesetzten Software erkennen und eine Ausführung der manipulierten Software verhindern. [<=]

A_22851 - Ausschluss von Manipulationen an der Hardware der VAU

Die VAU des sektoralen IDP MUSS die Integrität der eingesetzten Hardware schützen und damit insbesondere Manipulationen an der Hardware sowohl durch Dritte als auch der Betreiber des sektoralen IDP ausschließen. [<=]

A_22852 - Kontinuierliche Wirksamkeit des Manipulationsschutzes der VAU

Die VAU des sektoralen IDP MUSS den Ausschluss von Manipulationen an der Hardware und der Software sowohl durch Dritte als auch der Betreiber des sektoralen IDP mit Mitteln umsetzen, deren dauerhafte und kontinuierliche Wirksamkeit gewährleistet werden kann. [<=]

A_22853 - Ausschluss von Manipulationen über physische Angriffe

Die VAU des sektoralen IDP MUSS mit technischen und/oder organisatorischen Mitteln ausschließen, dass ein Angreifer aus dem betrieblichen Umfeld des IDP physische Angriffsmittel zur Kompromittierung der VAU zum Einsatz bringen kann. [<=]

A_22854 - Nutzdatenbereinigung vor physischem Zugang zu Systemen der VAU

Die VAU des sektoralen IDP MUSS mit technischen und/oder organisatorischen Mitteln sicherstellen, dass physischer Zugang zu Hardware-Komponenten der Verarbeitungskontexte nur erfolgen kann, nachdem gewährleistet ist, dass aus ihnen keine Nutzdaten extrahiert werden können. [<=]

A_22868 - Private Schlüssel im HSM

Der sektorale IDP MUSS folgende private Schlüssel in einem Hardware Security Module (HSM) erzeugen und anwenden: 

• die Schlüssel zur Signatur von Token und Entity Statements
• die Schlüssel der TLS-Zertifikate für die sichere Verbindung zum Verarbeitungskontext
  

A_22855 - HSM-Kryptographieschnittstelle verfügbar nur für Instanzen der VAU

Die VAU des sektoralen IDP MUSS mit technischen Mitteln die Manipulationen sowohl durch Dritte als auch den Betreiber des sektoralen IDP ausschließen und gewährleisten, dass nur Instanzen der VAU-Zugriff auf die Kryptographie Schnittstelle des HSM zur Nutzung des privaten Schlüsselmaterials für ihre TLS-Zertifikate und die Signaturschlüssel für die Token und Entity Statements erhalten können. [<=]

A_22856 - Konsistenter Systemzustand des Verarbeitungskontextes der VAU

Die VAU des sektoralen IDP MUSS sicherstellen, dass ein konsistenter Zustand des Verarbeitungskontextes auch bei Bedienfehlern oder technischen Problemen immer erhalten bleibt bzw. wiederhergestellt werden kann. [<=]

A_22567-01 - Informationsverpflichtung über Mandanten des Anbieters sektoraler IDP KTR

Der Anbieter sektoraler IDP KTR MUSS der gematik initial zur Zulassung und danach jeweils bei Änderungen tagesaktuell die Liste der Mandanten (Versicherungen) mitteilen, für deren Versicherte er den Dienst anbietet.
Zusätzlich MUSS der Anbieter sektoraler IDP KTR für GKV-Kassen die gemIK gemäß [A_25078*] und die Telematik-ID der Kasse aus dem "Verfahren zur Herausgabe der SMC-B für Kostenträger" nennen, in welchem der GKV-SV die Echtheit der Kasse bereits bestätigt hat und für Unternehmen nach §362 (1) SGB V (PKV-Kassen, Postbeamtenkrankenkasse, Bundeswehr ... ) die gemIK gemäß [A_25078*] und die Telematik-ID des Unternehmens aus dem "Verfahren zur Herausgabe der SMC-B" nennen. Die Beauftragung der Kasse bzw. des Unternehmens ist der Meldung schriftlich als Erklärung beizufügen.

Hinweis: Die Benachrichtigung an die gematik kann per E-Mail (S/MIME) an transition@gematik.de erfolgen.
[<=]

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 2: Teilnehmer Validierung Abfrage - Request-Parameter

A_28195 - Anbieter sektoraler IDP - Schlüssel-Identifier im JWK-Format

Der Anbieter des sektoralen IDP MUSS sicherstellen, dass bei der Bereitstellung neuer Schlüssel im JSON Web Key Set (JWKS) Format die Key Identifier der Schlüssel im UUID7-Format [RFC9562#name-uuid-version-7] vorliegen, die den Zeitpunkt der Schlüsselerzeugung widerspiegeln. [<=]

A_22643-02 - Entity Statement des sektoralen IDP

Der sektorale IDP MUSS ein selbst signiertes 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 3: Header des Entity Statement des sektoralen IDP

Tabelle 5 : Attribute des Metadatenblocks openid_provider im well-known-Dokument des sektoralen IDP

A_24403 - Signalisierung der Unterstützung von Claims

Der sektorale IDP MUSS in seinem metadata Statement über den Parameter claims_supported signalisieren, welche Claims er unterstützt. [<=]

A_28196 - Anbieter sektoraler IDP - Schlüsselwechselphase - Nutzbarkeit der ENC-Schlüssel

Der Anbieter des sektoralen IDP MUSS sicherstellen, dass die privaten Schlüssel von Schlüsselpaaren, deren Zweck die Verschlüsselung ist, systemintern so lange zur Entschlüsselung verwendet werden können, bis der Ablaufzeitpunkt ("exp" claim) des signierten Dokuments (Enitity Statement bzw. jwks) erreicht wurde, in dem der Schlüssel zuletzt bekannt gemacht wurde. [<=]

A_22711 - Regelmäßige Erneuerung des Entity Statement des sektoralen IDP

Das Entity Statement des sektoralen IDP MUSS täglich neu ausgestellt werden. [<=]

A_23010 - Maximale Gültigkeitsdauer eines Entity Statement des sektoralen IDP

Die maximale Gültigkeitsdauer eines Entity Statement des sektoralen IDP (Attributwerte iat und exp im Entity Statement) DARF 24 Stunden NICHT überschreiten. [<=]

A_22644 - Entity Statement - Prüfung angebotener URLs

Der sektorale IDP MUSS alle von ihm im Entity Statement angebotenen URL stündlich auf bloße Erreichbarkeit prüfen. [<=]

A_27506 - Signalisierung der unterstützten TI-Features durch einen sektoralen IDP der TI-Föderation

Ein sektoraler IDP MUSS in seinem Entity Statement im Metadatenblock openid_provider in einem Claim ti_features_supported signalisieren, welche spezifischen Versionen der TI-Föderation unterstützt werden. Im Claim ti_features_supported MUSS der sektoraler IDP aktuell die Unterstützung der in Tabelle "Durch einen sektoralen IDP unterstützte TI-Features" genannten Claims signalisieren.

Tabelle 6 : Durch einen sektoralen IDP unterstütze TI-Features

A_22649 - Anfragen unbekannter Clients

Der Produkttyp sektoraler IDP MUSS Pushed Authorization Request von Clients mit dem http-Statuscode 401 (Unauthorized) ablehnen, wenn diese nicht in der Föderation oder direkt beim sektoralen IDP registriert sind. Ist der Fachdienst dem sektoralen IDP nicht bekannt, so stößt dieser intern die automatische Registrierung [OpenID Federation 1.1] an damit nachfolgende Anfragen angenommen werden können. [<=]

A_22922 - Anfragen veralteter Authenticator Versionen

Der Produkttyp sektoraler IDP MUSS Authorization Request von veralteten Authenticator Versionen ablehnen, wenn diese aus Kompatibilitätsgründen durch die gematik gesperrt wurden. [<=]

A_22650-01 - Automatische Registrierung von Fachdiensten

Der sektorale IDP MUSS eine automatische Registrierung eines Fachdienstes Authorization Servers bei Übermittlung eines Authorization Request mit self_signed_tls_client_auth gemäß [OpenID Federation 1.1] durchführen, sofern dieser Dienst nicht bereits am IDP registriert wurde. Der sektorale IDP MUSS das Entity Statement des Fachdienst Authorization Server abrufen und gemäß A_28848* validieren. Anschließend registriert der sektorale IDP den Fachdienst Authorization Server und importiert dessen Schlüssel für die Authentisierung und Verschlüsselung von Token. [<=]

A_22651 - Parameter des Pushed Authorization Request durch den sektoralen IDP

Der sektorale IDP MUSS die Annahme von Pushed Authorization Request gemäß [OAuth 2.0 Pushed Authorization Requests#section-2] unterstützen und den Endpoint für Pushed Authorization Request im Entity Statement des sektoralen IDP pushed_authorization_request_endpoint bekanntgeben.
Der sektorale IDP MUSS mindestens die in der  Tabelle Parameter Pushed Authorization Request dargestellten Parameter im Pushed Authorization Request des Authorization Server eines Fachdienstes annehmen. 

A_24404 - Unterstützung von Claims im Authorization Request

Der sektorale IDP MUSS den Parameter Claims im Pushed Authorization Request verarbeiten können und dies in seinem metadata Statement über den Parameter claims_parameter_supported signalisieren. [<=]

A_22966-02 - Prüfung eingehender Pushed Authorization Request durch den sektoralen IDP

Der sektorale IDP MUSS eingehende Pushed Authorization Requests validieren und invalide Requests gemäß [OAuth 2.0 Pushed Authorization Requests#section-2.3] mit einer Fehlermeldung ablehnen. 
Die Validierung eines eingegangenen Pushed Authorization Request MUSS die Prüfung der im Request enthaltenen Werte für redirect_uri, scope und claims beinhalten. Dabei müssen redirect_uri, scope und claims aus dem Pushed Authorization Request eine Teilmenge der Werte sein, die der Federation Master für diesen Fachdienst in der Teilnehmerauskunft liefert.
[<=]

A_22991 - Prüfung des TLS Clientzertifikates am PAR-Endpunkt des sektoralen IDP

Der PAR-Endpunkt des sektoralen IDP MUSS das im Rahmen der self_signed_tls_client_auth übertragene Zertifikat des Fachdienstes wie folgt überprüfen:

• Das Zertifikat ist über das Entity Statement des Fachdienstes zu verifizieren.
• Das Zertifikat ist zeitlich gültig.

A_22992 - Antwort auf einen eingehenden Pushed Authorization Request durch den sektoralen IDP

Der sektorale IDP MUSS auf einen validen Pushed Authorization Request mit einem http-Statuscode 201 gemäß [RFC9126#section-2.2] antworten. [<=]

A_22993 - Gültigkeit der vom sektoralen IDP erstellten Request-URI

Die Gültigkeit der vom sektoralen IDP erstellten Request-URI DARF NICHT 90 Sekunden überschreiten. [<=]

A_22312-02 - Einhaltung der Standards bei der Realisierung des Authorization-Endpunkts

Der sektorale Identity Provider MUSS die Schnittstelle Authorization-Endpunkt gemäß [RFC6749#section-3.1], [RFC8252] und [RFC9126#section-4] sowie weitere darin festgelegte Standards implementieren. Hierbei MÜSSEN nur im Rahmen der [gemSpec_IDP_Sek] relevante Aspekte berücksichtigt werden.
[<=]

A_22324 - Verwendung des Attributes "state" durch sektoralen IDP

Der Authorization-Endpunkt des sektoralen Identity Provider MUSS den state-Parameter [RFC6749#section-10.12] der Anfrage in allen darauf basierenden Responses verwenden. [<=]

A_22325-01 - Übermitteln des "AUTHORIZATION_CODE" an den Sender des Requests

Der sektorale Identity Provider MUSS den AUTHORIZATION_CODE und den state auf demselben Kanal beantworten, auf dem er den Authorization Request empfangen hat.
[<=]

A_22653 - Annahme von "AUTHORIZATION_CODE" und "CODE_VERIFIER"

Der Token-Endpunkt des sektoralen IDP MUSS die vom Authorization Server eines Fachdienstes übertragenen AUTHORIZATION_CODE und CODE_VERIFIER annehmen. [<=]

A_23007 - Gültigkeit des "AUTHORIZATION_CODE"

Die Gültigkeitsdauer eines AUTHORIZATION_CODE DARF 90 Sekunden NICHT überschreiten. [<=]

A_23162 - Invalidisierung des "AUTHORIZATION_CODE"

Der AUTHORIZATION_CODE MUSS nach einmaliger Verwendung invalidiert werden. [<=]

A_22321 - Prüfung des "CODE_VERIFIER"

Der Token-Endpunkt des sektoralen Identity Provider MUSS die Überprüfung des CODE_VERIFIER gegen die CODE_CHALLENGE mit S256 (Algorithmus nach [RFC7636#section-4.2]) durchführen. [<=]

A_22654 - Prüfung des TLS Clientzertifikates am Token-Endpunkt des sektoralen IDP

Der Token-Endpunkt des sektoralen IDP MUSS das im Rahmen der self_signed_tls_client_auth übertragene Zertifikat des Fachdienstes wie folgt überprüfen:

• Das Zertifikat ist über das Entity Statement des Fachdienstes zu verifizieren.
• Das Zertifikat ist zeitlich gültig.

A_22323 - Protokollierung der Token-Ausgabe in allen Fällen

Der Token-Endpunkt des sektoralen Identity Provider MUSS im Positivfall die Herausgabe der Token und im Negativfall die Token-Anfrage protokollieren. [<=]

A_22316 - Maximale Gültigkeitsdauer von ID Token

Der sektorale Identity Provider DARF ID Token mit einer Gültigkeitsdauer von mehr als 300 Sekunden (5 Minuten) NICHT ausstellen. [<=]

A_22706-02 - "ID Token" des sektoralen IDP

Der sektorale IDP MUSS nach erfolgreicher Prüfung des erhaltenen AUTHORIZATION_CODE dem aufrufenden Authorization Server des Fachdienstes ein ID Token gemäß OIDC-Standard [OpenID Connect Core 1.0#IDToken] mit den angefragten Scope und Claims zurückgeben.
[<=]

A_22983 - Signaturverfahren für Signatur des "ID Token" des sektoralen IDP

Das für die Signatur der ID Token zu verwendende Verfahren MUSS ECDSA auf Basis der NIST-Kurve P-256 sein. (vergleiche [draft-jones-json-web-signature-04.html#DefiningECDSA]). [<=]

A_22655-03 - Signatur des "ID Token" des sektoralen IDP

Der sektorale IDP MUSS die ID Token unter Verwendung eines privaten Schlüssels, der zu einem direkt unter openid_provider.jwk im Entity Statement stehenden oder unter openid_provider.signed_jwks_uri referenzierten öffentlichen Schlüssel gehört, signieren [OpenID Federation 1.1].

Zum öffentlichen Schlüssel des verwendeten Schlüsselpaares MUSS es ein Signaturzertifikat des Typs C.FD.SIG und der technischen Rolle „oid_idpd_sek“ gemäß [gemSpec_Krypt#Abschnitt 3.7] aus der Komponenten-PKI der TI geben, welches im Parameter x5c des ID Token Headers enthalten ist. [<=]

A_23193-01 - Verschlüsseln der "ID Token"

Der sektorale IDP MUSS einen Verschlüsselungsschlüssel des Fachdienstes über den use Parameter ("use = enc") aus dessen jwks wählen und mit diesem das ID Token verschlüsseln. Im JWE-Header des Token referenziert der sektorale IDP über den Parameter kid einen Hinweis auf den verwendeten Verschlüsselungsschlüssel. Als Verschlüsselungsverfahren MUSS hierbei ECDH-ES verwendet werden. [<=]

A_27598 - Unterstütze Versionen der von sektoralen IDPs ausgestellten ID Token

Der sektorale IDP MUSS den Claim metadata.openid_relying_party.ti_features_supported.id_token_version_supported aus dem Entity Statement des anfragenden Fachdienstes auswerten und die jeweils höchste von beiden Seiten unterstützte Version für das auszugebende ID Token auswählen. Gibt es keine passende Übereinstimmung der unterstützten ID Token Versionen, so MUSS der IDP am PAR-Endpunkt den Request mit dem Fehlercode HTTP-400 "Invalid_metadata" (gemäß [OpenID Federation 1.1]) ablehnen. Aus der error_description der Fehlermeldung MUSS eindeutig der Grund der Ablehnung hervorgehen. [<=]

A_27713-01 - Signalisierung der vom sektoralen IDP ausgestellten ID Token-Version

Der sektorale IDP MUSS die Version des ausgestellten ID Token im custom Claim "version" im JWE Protected Header angeben.
[<=]

A_22989-02 - "Scope" und "Claims" Werte des sektoralen IDP für Versicherte

Ein sektoraler IDP, welcher die Identitäten für Versicherte verwaltet, MUSS mindestens die folgenden Scope und Claims Werte unterstützen:

Tabelle 7: Scope und Claims

A_23197-01 - Nutzung eines pairwise Subject als Pseudonym des Versicherten

Der sektorale IDP MUSS das Attribut sub gemäß [openid-connect-core-1_0.html#PairwiseAlg] als pairwise Subject Identifiers bilden. Dieses wird als pseudonyme ID des Versicherten verwendet:

• Der Subject Identifier MUSS je Versichertem und Fachdienst fest und eineindeutig sein.
• Der Subject Identifier MUSS sich für einen Versicherten gegenüber jedem Fachdienst unterscheiden.

A_22990-01 - Umgang mit fehlenden oder verwehrten Informationen

Ein sektoraler IDP MUSS, wenn ihm der Wert eines Scopes nicht vorliegt und es keine Regel für eine Alternativbelegung gibt (siehe z. B. Belegungsregel "birthday" in A_22989*) oder ein Scope vom Nutzer verwehrt wurde, diesem Scope entsprechende Claims im ID Token unterdrücken. Explizit (durch einen Request-Parameter claims) angefragte Claims DARF ein IDP NICHT im ID Token zurückliefern, wenn der Claim keinen Wert enthält oder die Nutzer-Zustimmung zur Weitergabe nicht erteilt wurde. [<=]

A_23024 - Definition "gematik-ehealth-loa-substantial"

Der Anbieter des sektoralen IDP MUSS gematik-ehealth-loa-substantial wie folgt interpretieren: 
Der Wert gematik-ehealth-loa-substantial entspricht der Widerstandsfähigkeit des Authentisierungsmittels und Protokolls gegen das Angriffspotential "moderate" nach [ISO18045].
Zertifizierungen, Notifizierung  oder Bestätigungen von Prozessen oder Prozessbestandteilen vergleichbarer Normen und Richtlinien, z. B. nach Verordnung (EU) Nr. 910/2014 in Verbindung mit (EU) 2015/1502 an elektronische Identifizierungsmittel, BSI TR-03107-1 oder vergleichbar, können nachgenutzt werden. [<=]

A_23025 - Definition "gematik-ehealth-loa-high"

Der Anbieter des sektoralen IDP MUSS gematik-ehealth-loa-high wie folgt interpretieren: 
Der Wert gematik-ehealth-loa-high entspricht der Widerstandsfähigkeit des Authentisierungsmittels und Protokolls gegen das Angriffspotential "high" nach [ISO18045].
Zertifizierungen, Notifizierung  oder Bestätigungen von Prozessen oder Prozessbestandteilen vergleichbarer Normen und Richtlinien, z. B. nach Verordnung (EU) Nr. 910/2014 in Verbindung mit (EU) 2015/1502 an elektronische Identifizierungsmittel, BSI TR-03107-1 oder vergleichbar, können nachgenutzt werden. [<=]

A_22987 - Claim "acr" für eine "gematik-ehealth-loa-substantial" Authentisierungsstärke

Der Anbieter des sektoralen IDP MUSS sicherstellen das der Claim acr nur auf den Wert gematik-ehealth-loa-substantial gesetzt wird, wenn der Nutzer mindestens auf dem Niveau "substanziell" authentisiert wurde (siehe A_23024 - Definition "gematik-ehealth-loa-substantial"). [<=]

A_22988 - Claim "acr" für eine "gematik-ehealth-loa-high" Authentisierungsstärke

Der Anbieter des sektoralen IDP MUSS sicherstellen das der Claim acr nur auf den Wert gematik-ehealth-loa-high gesetzt wird, wenn der Nutzer auf dem Niveau "hoch" authentisiert wurde (siehe A_23025 - Definition "gematik-ehealth-loa-high"). [<=]

A_22865-01 - Verpflichtende Verfahren zur Identifikation von Nutzern

Der Anbieter des sektoralen IDP MUSS einen Prozess zur Identifikation von Nutzern mit mindestens diesen Identifikationsverfahren zur Nutzeridentifikation anbieten:

• Identifikation mittels elektronischen Identitätsnachweises (online Ausweisfunktion)
• Identifikation mittels eGK und PIN
• Identifikation mittels PID aus einer zertifizierten EUDI-Wallet

A_22334-01 - Verifikation des Versicherten vor erster Nutzung

Der Anbieter des sektoralen IDP MUSS sicherstellen, dass der Zuordnungsprozess zwischen einer natürlichen Person und den Daten der Attributbestätigenden Stelle eindeutig ist.
[<=]

A_23102 - Weitere Verfahren zur Identifikation von Nutzern

Alle Verfahren zur Identifikation des Nutzers müssen dem Angriffspotential high nach ISO 18045 standhalten. Die Bewertung der Zulässigkeit der Identifikationsverfahren erfolgt in Einzelprüfung durch die gematik.  [<=]

A_22712 - Unterstützung von NFC eGK und PIN

Der Hersteller eines sektoralen IDP MUSS ein Authentifizierungsverfahren über NFC mittels eGK und PIN unterstützen. [<=]

A_22713 - Unterstützung des elektronischen Identitätsnachweis (online-Ausweisfunktion)

Der Hersteller eines sektoralen IDP MUSS ein Authentifizierungsverfahren mittels elektronischem Identitätsnachweis (Online-Ausweisfunktion) unterstützen. [<=]

A_28990 - Unterstützung der EUDI-Wallet

Der Hersteller eines sektoralen IDP MUSS ein Authentifizierungsverfahren mittels PID aus einer zertifizierten EUDI-Wallet unterstützen. [<=]

A_23026 - Entfernen von Authentifizierungsverfahren, welche die Vorgaben nicht mehr erfüllen

Der Anbieter eines sektoralen IDP MUSS sicherstellen, dass Authentifizierungsverfahren entfernt/ausgeschlossen werden, wenn sie das entsprechende Sicherheitsniveau gematik-ehealth-loa-high bzw. gematik-ehealth-loa-substantial nicht mehr erfüllen. [<=]

A_24547-01 - Anfrage spezifischer Authentisierungsmittel (amr) durch Relying Parties

Ein sektoraler IDP MUSS die Anfrage von Relying Parties zum Einsatz bestimmter Authentisierungsmittel im Claims-Parameter des Authorization Request durch Verwendung des amr (authentication_method_reference) Claims (gemäß [OpenID Connect Core 1.0#IDToken] ein JSON Array) unterstützen.

• Signalisiert eine Relying Party im Authorization Request die amr-Präferenz ohne das Attribut essential oder mit dem Attribut essential und dem Wert false, so SOLL der sektorale IDP diese Authentisierungsmittel in absteigender Reihenfolge der Auflistung bei der Authentisierung des Nutzers berücksichtigen. Wurde ein aufgelistetes Authentisierungsmittel erfolgreich verwendet, so ist auf die Prüfung weiterer Authentisierungsmittel zu verzichten. Konnte kein angefordertes Authentisierungsmittel erfolgreich verwendet werden, so liegt es im Ermessen des sektoralen IDP, unter Berücksichtigung der Nutzerpräferenzen, welches Authentisierungsmittel zur Erfüllung des Authorization Request erforderlich ist.

• Signalisiert eine Relying Party im Authorization Request die amr-Präferenz mit dem Attribut essential und dem Wert true, so MUSS der sektorale IDP diese Authentisierungsmittel in absteigender Reihenfolge der Auflistung bei der Authentisierung des Nutzers berücksichtigen. Wurde ein aufgelistetes Authentisierungsmittel erfolgreich verwendet, so ist auf die Prüfung weiterer Authentisierungsmittel zu verzichten. Konnte kein angefordertes Authentisierungsmittel erfolgreich verwendet werden, so ist die Authentisierung mit einem Fehler (siehe [OpenID Connect Core 1.0#AuthError]) abzubrechen.
  

A_25753 - Verfahren zum Erzwingen einer Authentisierung des Nutzers

Der sektorale IDP MUSS mindestens die Verfahren "max_age=0" und "prompt=login" zur Durchsetzung der Benutzerauthentifizierung unterstützen.  Verpflichtende Parameter, die sich daraus ergeben (z.B. auth_time), MÜSSEN gemäß [https://openid.net/specs/openid-connect-core-1_0.html] berücksichtigt werden. [<=]

A_23129-06 - Identifikation des Authentisierungsverfahren

Der sektorale IDP MUSS den Claim amr im ID_TOKEN entsprechend dem durchgeführten Authentisierungsverfahren nach folgender Tabelle befüllen.

Tabelle 8: Codierung der Authentisierungsverfahren

A_25239-01 - Authentifizierung mit eGK+PIN ohne Prüfung Gerätebindung (Gastzugang)

der sektorale IDP MUSS über sein Authenticator-Modul die Authentifizierung eines Nutzers mit eGK+PIN ohne Prüfung oder Anlegen einer Gerätebindung unterstützen, wenn eine Relying Party eine Nutzer-Authentifizierung urn:telematik:auth:guest:eGK beim sektoralen IDP anfordert. In diesem Fall MUSS, nach Übertragung des Zertifikates durch das Authenticator-Modul an den sektoralen IDP, dieser:

• die Gültigkeit und Signatur des AUT-Zertifikats der eGK prüfen,
• das Authentisierungsverfahren gegen Replay-Angriffe schützen,
• mittels Signaturanforderung das Vorliegen der korrekten PIN sicherstellen,
• sicherstellen, dass der öffentliche Schlüssel des AUT-Zertifikats dem öffentlichen Schlüssel aus der angeforderten Signatur entspricht,
• die Attribute des AUT-Zertifikats für die Erstellung des ID Token verwenden. 

A_22867-01 - Signalisierung der Verwendung des Authentisierungsverfahrens "gematik-ehealth-loa-substantial" beim Zugriff auf Daten mit hohem Schutzbedarf (befristet)

Der sektoraler IDP MUSS den Claim amr um den Wert "urn:telematik:auth:mEW" erweitern, wenn der Fachdienst eine Authentifizierung des Nutzers auf dem Niveau gematik-ehealth-loa-high angefragt hat, der Nutzer jedoch ein Authentisierungsverfahren auf dem Niveau gematik-ehealth-loa-substantial verwendet hat. Die Einwilligung des Anwenders zur Nutzung dieses Verfahrens zum Zugriff auf Daten mit hohem Schutzbedarf MUSS vorliegen.  [<=]

A_27591 - Signalisierung der Einwilligung durch den Nutzer in "gematik-ehealth-loa-substantial" beim Zugriff auf Daten mit hohem Schutzbedarf

Der sektorale IDP MUSS in den Custom Claim urn:telematik:auth:consent den Wert loa-substantial ergänzen, wenn der Fachdienst eine Authentisierung des Nutzers auf dem Niveau gematik-ehealth-loa-high angefragt, der Nutzer jedoch ein Authentisierungsverfahren auf dem Niveau gematik-ehealth-loa-substantial verwendet hat und die Einwilligung des Anwenders zur Nutzung dieses Verfahrens zum Zugriff auf Daten mit hohem Schutzbedarf vorliegt. [<=]

A_23103-01 - Einwilligung zur Verwendung des Authentisierungsverfahrens "gematik-ehealth-loa-substantial" beim Zugriff auf Daten mit hohem Schutzbedarf

Vor der Nutzung von Authentisierungsverfahren mit substantiellem Schutzniveau beim Zugriff auf Daten mit hohem Schutzbedarf nach A_22867 MUSS der sektorale IDP sicherstellen, dass die Einwilligung des Nutzers vollständig freiwillig erfolgt. Dabei müssen alternative Verfahren mit Sicherheitsniveau gematik-ehealth-loa-high hervorgehoben und die Möglichkeit des Widerrufs der Einwilligungserklärung aufgezeigt werden. Der Nutzer muss insbesondere über die Risiken einer Absenkung des Vertrauensniveaus informiert werden und der Verwendung eines Verfahrens mit einem anderen angemessenen Sicherheitsniveau zum Zugriff auf Daten mit hohem Schutzbedarf aktiv zustimmen.
[<=]

A_25248 - Protokollierung der Einwilligung zur Verwendung von Authentisierungsverfahren "gematik-ehealth-loa-substantial"

Der sektorale IDP MUSS die Einwilligung des Nutzers zur Verwendung des Authentisierungsverfahrens gematik-ehealth-loa-substantial protokollieren. [<=]

A_22744 - Authenticator auf Zweitgerät

Der Hersteller eines sektoralen IDP MUSS ein technisches Verfahren für den Fall etablieren, dass ein Nutzer das Authenticator-Modul auf einem anderen Gerät betreibt als die Frontend Komponente des  Fachdienstes, welcher eine Authentifizierung beim sektoralen IDP angefragt hat. In diesem Fall MUSS der sektorale IDP für den Auth-Endpunkt ein WebFrontend bieten, welches die weitere Authentisierung über einen Authenticator auf einem anderen Gerät ermöglicht. [<=]

A_22306-01 - Information des Nutzers bei fehlender Installation des gewählten Authenticator-Moduls

Der Hersteller eines sektoralen IDP MUSS ein technisches Verfahren für den Fall etablieren, dass ein Nutzer das Authenticator-Modul nicht installiert hat. In diesem Fall MUSS der sektorale IDP für den Auth-Endpunkt ein WebFrontend anbieten und dort darstellen, aus welcher Quelle das jeweilige Authenticator-Modul des sektoralen Identity Provider zu beziehen ist, auf welchen Geräten/Plattformen es installiert werden kann und welche Voraussetzungen für die Verwendung zur Authentifizierung zu erfüllen sind (z. B. erforderliche Registrierungsprozeduren beim Anbieter des sektoralen Identity Provider). [<=]

A_22257 - Operationsaufruf erfordert erfolgreiche Authentifizierung

Der sektorale Identity Provider MUSS sicherstellen, dass Authorization Request nur nach vorheriger erfolgreicher Authentifikation des Nutzers mit einem AUTHORIZATION_CODE beantwortet werden. [<=]

A_22235 - Information des Versicherten über Änderungen an Authentifizierungsfaktoren

Der Anbieter des sektoralen Identity Provider MUSS den Versicherten über Änderungen an Authentifizierungsfaktoren informieren.
Die Information des Versicherten kann dabei auch über die Attributbestätigende Stelle erfolgen, welche den Anbieter des sektoralen Identity Provider mit der Erstellung des elektronischen Identifizierungsmittels beauftragt hat. [<=]

A_22236-01 - Auskunft an Versicherten

Der Anbieter des sektoralen Identity Provider MUSS dem Versicherten auf dessen Verlangen Auskunft geben über:

• erfolgte Zugriffe auf das elektronische Authentisierungsmittel des Versicherten
• Änderungen der Authentifizierungsfaktoren des Versicherten
• Einwilligungen zur Verwendung des Authentisierungsverfahrens gematik-ehealth-loa-substantial

A_23623 - Wahlfreiheit des Authentisierungsverfahren für TI-Anwendungen

Wenn der sektorale IDP neben dem elektronischen Identitätsnachweis (Online-Ausweisfunktion) und eGK+PIN weitere Authentisierungsverfahren auf dem Niveau gematik-ehealth-loa-high anbietet, so MUSS dem Nutzer die Möglichkeit gegeben werden auszuwählen, welche Verfahren (Online-Ausweisfunktion, eGK+PIN, weitere) für die Authentisierung bei TI-Fachanwendungen verwendet werden dürfen.
Dabei MUSS der sektorale IDP eine beliebige Auswahl (mindestens einer) der bereitgestellten Authentisierungsmethoden  ermöglichen. Der Nutzer MUSS die Möglichkeit haben diese Auswahl zu ändern sowie ein bevorzugtes Verfahren festzulegen. [<=]

A_22750-02 - Gerätebindung und Authentisierung für "gematik-ehealth-loa-high" und "gematik-ehealth-loa-substantial" (befristet bis 02.01.2027)

Abhängig von der Geräteausstattung des Nutzers ist eine Gerätebindung für einen festgelegten Zeitraum ohne Erneuerung gültig. Der Anbieter des sektoralen IDP MUSS, wenn er eine Gerätebindung im Rahmen eines Authentisierungsverfahren nutzt, die Zeitrahmen der Gültigkeit für die Gerätebindung gemäß Tabelle "Übersicht Gerätebindung" berücksichtigen.
Beim Zugriff auf Daten mit hohem Schutzbedarf gelten die Zeiträume der maximalen Gerätebindung gematik-ehealth-loa-high in der Tabelle. Nach Einwilligung des Nutzers gemäß A_23103* gelten beim Zugriff auf Daten mit hohem Schutzbedarf, unter Verwendung von Authentisierungsverfahrens gematik-ehealth-loa-substantial die Zeiträume der maximalen Gerätebindung gematik-ehealth-loa-substantial in Tabelle "Übersicht Gerätebindung". 
Die Gerätebindung MUSS durch den Nutzer nach Ablauf dieser Frist dementsprechend erneuert werden.
Der Anbieter des sektoralen IDP MUSS mit den zur Verfügung stehenden Plattformmechanismen, einen kryptographischen Nachweis der Gerätebindung auf dem Endgerät erzeugen und auf Serverseite prüfen (z.B. Android: Key & ID Attestation; iOS: DCAppAttestService).
Die Gerätebindung kann:

1. durch Identifikation, welche dem Niveau gematik-ehealth-loa-high entspricht oder  
2. mit einer 2FA, welche dem Niveau gematik-ehealth-loa-high entspricht,

Tabelle 9: Übersicht Gerätebindung

A_23700-01 - Verwendung der Gerätesperre als Faktor zur Nutzerauthentifizierung

Ein sektoraler IDP KANN als Wissensfaktor für Android- und iOS-Geräte die vom Nutzer vergebene System-PIN oder das System-Passwort verwenden. Für die Nutzung der System-PIN MUSS die Einwilligung des Nutzers zur Verwendung des Authentisierungsverfahrens gematik-ehealth-loa-substantial beim Zugriff auf Daten mit hohem Schutzbedarf [A_23103] vorliegen. [<=]

A_25138-01 - Erneuerung der Gerätebindung für "gematik-ehealth-loa-high"

Nach Ablauf der Gültigkeitsdauer einer Gerätebindung DARF die bestehende Gerätebindung NICHT als Authentisierungsfaktor für die Erneuerung der Gerätebindung für gematik-ehealth-loa-high verwendet werden.
[<=]

A_23699 - Erstellung oder Erneuerung einer Gerätebindung an eine Nutzeridentität

Der Hersteller des sektoralen IDP MUSS zur Erstellung oder Erneuerung der Gerätebindung eine Identifizierung oder Authentifizierung des Nutzers auf dem Vertrauensniveau "gematik-ehealth-loa-high" durchführen. Die Nutzung einer bestehenden Gerätebindung zur Erneuerung einer Gerätebindung an eine Nutzeridentität ist gemäß A_25138 ausgeschlossen. [<=]

A_25969 - Keine Nutzung einer Gerätebindung zur Einrichtung einer Gerätebindung

Eine Gerätebindung DARF NICHT mittels einer bestehenden Gerätebindung neu eingerichtet werden. [<=]

A_23701-02 - Verwendung von Biometrie als Faktor zur Nutzerauthentifizierung

Der Anbieter des sektoralen IDP MUSS für die Nutzung von biometrischen Sensoren zur Nutzerauthentifizierung die in der Tabelle "Biometrie" aufgeführten Einschränkungen berücksichtigen. Für die Nutzung eines biometrischen Faktors MUSS, wenn damit eine Herabstufung des Vertrauensniveaus verbunden ist, die Einwilligung des Nutzers zur Verwendung des Authentisierungsverfahrens gematik-ehealth-loa-substantial beim Zugriff auf Daten mit hohem Schutzbedarf [A_23103] vorliegen.

Tabelle 10: Biometrie

A_26591 - Einwilligung zur Verwendung biometrischer Sensoren

Der sektorale IDP MUSS die explizite Einwilligung zur Verwendung der in Tabelle "Biometrie" zugelassenen biometrischen Sensoren einholen, wenn diese Sensoren nicht die erforderliche Güte für die uneingeschränkte Nutzung auf dem Vertrauensniveau gematik-ehealth-loa-substantial beziehungsweise gematik-ehealth-loa-high erfüllen. Dabei MUSS der sektorale IDP sicherstellen, dass der Nutzer über die damit verbundenen Risiken hinreichend informiert wurde, die Einwilligung des Nutzers vollständig freiwillig erfolgt und die Einwilligung kryptografisch abgesichert ist.
Diese Einwilligung MUSS durch den sektoralen IDP für jedes Endgerät eingeholt werden, auf dem biometrische Sensoren verwendet werden, unabhängig von bereits erfolgten Einwilligungen auf anderen Endgeräten. Der sektorale IDP MUSS sicherstellen, dass erteilte Einwilligungen auf den jeweiligen Geräten durch den Nutzer für dieses Gerät widerrufen werden können.
[<=]

A_23207-02 - Single-Sign-On (SSO) als Authentifizierungsverfahren (befristet)

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS im Claim acr das Niveau beauskunften, welcher dem der vorhergehenden Authentisierung entspricht. Der Claim amr MUSS um den Wert urn:telematik:auth:sso gemäß der Tabelle "Codierung der Authentisierungsverfahren" erweitert werden. [<=]

A_27592 - Signalisierung Single-Sign-On (SSO) als Authentifizierungsverfahren im ID Token

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS das Niveau im ID Token im Claim acr bestätigen, welches dem der vorhergehenden Authentifizierung entspricht. Der Custom Claim urn:telematik:auth:interactive MUSS im ID Token auf den Wert silent gesetzt werden, wenn eine SSO-Authentisierung ohne Benutzerinteraktion durchgeführt wurde. [<=]

A_23208-03 - Zustimmung des Nutzer für SSO

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS, sofern die SSO-Präferenzen im Authenticator-Modul verwaltet werden, vor der Aktivierung eines SSO sicherstellen, dass die Einwilligung des Nutzers hierzu insbesondere aufgeklärt, vollständig freiwillig, unter Hervorhebung sichererer Verfahren und widerrufbar erfolgte. Der Nutzer MUSS über die Risiken des SSO ausreichend aufgeklärt werden und der Verwendung für jeden einzelnen Fachdienst aktiv zustimmen.
Hinweis 1: Die Anforderung gilt für die zeitlich befristete Übergangslösung. Diese wird von einer ePA-FdV unabhängigen SSO-Lösung nach Abnahme durch das BSI abgelöst.
Hinweis 2: SSO für TI-Anwendungen in einem ePA-FdV wird dort verwaltet und ist nicht Gegenstand dieser Anforderung.
Hinweis 3: Diese Anforderung soll sicherstellen, dass z.B. für Funktionen einer Kasse ein sicheres SSO ermöglicht wird. [<=]

A_24721-02 - Ausstellen einer SessionID zu einem Anwendungskontext

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO im Ablauf der ersten erfolgreichen Nutzerauthentisierung eine SessionID zum laufenden Nutzerkontext generieren und dem Authenticator-Modul des Anwendungskontextes übertragen. Der Hersteller MUSS sicherstellen, dass eine ausgestellte SessionID nur nach erfolgreicher Authentisierung und ausschließlich für den jeweiligen Nutzerkontext verwendet werden kann und spätestens nach der in A_23212 festgelegten Zeitspanne nach der letzten Nutzerinteraktion am Authenticator-Modul oder durch explizite Signalisierung der Beendigung des Anwendungskontextes durch die Anwendung gelöscht wird. [<=]

A_24725-01 - Prüfung der SessionID zu einem Anwendungskontext

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO jede Nutzerauthentisierung ohne Nutzerinteraktion die Gültigkeit, der vom Authenticator-Modul übertragenen SessionID überprüfen indem:

• die Signatur der SessionID mit dem zum Nutzer und zur SessionID gespeicherten public Key validiert wird,
• die SessionID mit der zum Nutzer gespeicherten SessionID verglichen wird,
• der Gültigkeitszeitraum der SessionID überprüft wird.

A_23212-02 - Gültigkeitsdauer einer SessionID

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS sicherstellen, dass die vom sektoralen IDP zu einem Anwendungskontext ausgestellte SessionID ungültig wird und gelöscht werden muss, wenn:

• der Anwendungskontext, zu dem die SessionID erstellt wurde, beendet wurde
• der Nutzer bei offenem Anwendungskontext mindestens 10 Minuten inaktiv war
• die SessionID die maximale Gültigkeitsdauer von 1h überschreitet

A_22939-01 - Widerspruch zur Weitergabe einzelner Claims

Authenticator-Module des sektoralen IDP MÜSSEN dem Nutzer die Möglichkeit geben, einem Dienst einzelne Claims nicht zu übermitteln. Für die Diensterbringung unbedingt erforderliche Claims ("essential claims") sollen dabei als nicht abwählbar dargestellt werden.
[<=]

A_22832 - Authenticator-Modul: Anzeige des "user_consent"

Das Authenticator-Modul des sektoralen IDP MUSS die Willenserklärung des Nutzers zur Übermittlung seiner in den Claims angeforderten Daten an den anfragenden Fachdienst über ein für den Betreiber des sektoralen IDP nicht einsehbares Verfahren einholen.  [<=]

A_23051 - Authenticator-Module für Android und iOS

Der Anbieter des sektoralen Identity Provider MUSS den Nutzern Authenticator-Module für Android (im Google Play Store) und iOS (im App Store) bereitstellen. Weitere Verbreitungswege sind zulässig aber nicht verpflichtend. [<=]

A_22277-01 - Authenticator-Modul: Schutz vor überalterter Software

Der Anbieter des sektoralen Identity Provider MUSS dafür Sorge tragen, dass die in App Stores veröffentlichten Authenticator-Module schnellstmöglich aktualisiert und die Nutzer über Updates informiert werden. [<=]

A_23389-01 - Authenticator-Modul: Schutz vor Missbrauch

Das Authenticator-Modul für mobile Endgeräte des sektoralen IDP MUSS

• Geräte mit Jailbreak oder Root-Zugriff entsprechend dem aktuellen Stand der Technik erkennen. Das Authenticator-Modul MUSS dem Nutzer darstellen, welche Risiken für die Daten des Nutzers bestehen (z. B., dass diese offengelegt werden könnten) und die Fortsetzung unterbinden.
• den Start in einer Entwicklungs-/Debug-Umgebung sicher erkennen und unterbinden.
• den Start abbrechen, falls es unter ungewöhnlichen Benutzerrechten gestartet wird (z. B. root oder nobody).
• Zertifikats-Pinning für die Verbindung zum sektoralen IDP unterstützen. Es DARF Zertifikate NICHT akzeptieren, deren Zertifikatskette dem Hersteller nicht vertrauenswürdig erscheint [RFC746].

A_22659 - Realisierung der App2App-Kommunikation im Fall Android

Im Kontext von Android-Anwendungen MÜSSEN Authenticator-Module zu sektoralen IDP für die wechselseitige Verlinkung den unter [ANDROIDAPPLINKS] beschriebenen App-Link-Mechanismus verwenden und damit Aufrufe an die Adresse des Authorization-EP ermöglichen. [<=]

A_22660 - Realisierung der App2App-Kommunikation im Fall Apple/iOS

Im Kontext von iOS-Anwendungen MÜSSEN Authenticator-Module zu sektoralen IDP für die wechselseitige Verlinkung den unter [APPLEUNIVERSAL] beschriebenen Universal-Link-Mechanismus verwenden und damit Aufrufe an die Adresse des Authorization-EP ermöglichen. [<=]

A_22661 - Serverseitige Registrierungsdaten

Anbieter von sektoralen IDP MÜSSEN sicherstellen, dass die durch das Betriebssystem notwendigen Voraussetzungen für die Funktionsfähigkeit ihres Authenticator-Moduls erfüllt sind (z. B. Registrierung der Anwendung zur App2App-Kommunikation entsprechend der Mechanismen unter [ANDROIDAPPLINKS] bzw. [APPLEUNIVERSAL] zur Verknüpfung der Anwendung mit einer Webseite). [<=]

A_23203-01 - Zu unterstützende Betriebssystemversionen

Der Anbieter des sektoralen Identity Provider MUSS dafür Sorge tragen, dass seine Authenticator-Module für mobile Endgeräte jederzeit:

• iOS Betriebssystem: Die noch offiziell von Apple mit OS-Updates versorgten Geräte
• Android-Betriebssystem:  Versionen mindestens der letzten zwei Jahre 

A_22308-01 - Beschränkung des Authenticator-Moduls eines sektoralen IDP auf die Authentifizierung

Das Authenticator-Modul beim Aufruf durch das Anwendungsfrontend DARF NICHT weitere/andere Funktionalitäten anbieten als solche, die direkt oder indirekt zur Authentifizierung des Nutzers dienen (z. B. Einrichtung, Registrierung, dafür relevante Informationen). Insbesondere Werbung für andere Leistungen oder Funktionen DARF NICHT angezeigt werden. [<=]

A_22311 - Verwendung der ursprünglichen Adresse zur Übergabe des "AUTHORIZATION_CODE"

Authenticator-Module von sektoralen Identity Provider MÜSSEN die bei der Übergabe des Authorization Request erhaltene redirect_uri für die Übergabe des AUTHORIZATION_CODE verwenden. Außer für diesen Aufruf DARF er NICHT an andere Anwendungen übergeben werden. [<=]

A_22978-01 - Aufbereiten von Geräteinformationen

Authenticator-Module von sektoralen IDP für mobile Endgeräte SOLLEN Informationen zum verwendeten Endgerät des Nutzers erheben können welche die Inhalte des Datentyps "Device_Type" abbilden.
Um die Authentizität des Datensatzes zu gewährleisten, muss die Vertrauenswürdigkeit zum Zeitpunkt der Erhebung des Datensatzes geprüft und nachgewiesen werden.
Hierfür müssen geeignete und zur Verfügung stehende Plattformmechanismen genutzt werden (z. B. Android: SafetyNet Attestation / Integrity API, Key & ID Attestation; iOS: DCAppAttestService). [<=]

A_23031 - Authenticator-Modul: OAuth 2.0 Pushed Authorization Request (PAR)

Das Authenticator-Modul MUSS mittels App2App-Kommunikation übertragene Anfragen entsprechend [RFC9126#section-4] annehmen und gewährleisten, dass der Request TLS-gesichert in die vertrauenswürdige Ausführungsumgebung des sektoralen IDP übermittelt wird. [<=]

A_27586 - Authenticator-Modul: Widerruf von Nutzerpräferenzen

Das Authenticator-Modul eines sektoralen IDP MUSS den Nutzern die Möglichkeit zum Widerruf einer erteilten gespeicherten Willenserklärung zur Freigabe seiner Daten für die Nutzung durch Fachdienste bieten.
[<=]

A_24722-01 - Ausstellen eines Schlüssels zu einem Anwendungskontext

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO nach der ersten erfolgreichen Nutzerauthentisierung im Schlüsselspeicher des Nutzergerätes ein Schlüsselpaar generieren und an den laufenden Anwendungskontext sowie an der vom sektoralen IDP erhaltenen SessionID binden. Das Authenticator-Modul MUSS nach der ersten erfolgreichen Nutzerauthentisierung den öffentlichen Schlüssel und die mit dem privaten Schlüssel signierte SessionID zum Anwendungskontext an den sektoralen IDP übertragen. Der Hersteller von sektoralen IDP MUSS sicherstellen, dass das zu einem Anwendungskontext generierte Schlüsselpaar und SessionID nach dem Schließen des Anwendungskontextes aus dem Schlüsselspeicher des Geräts gelöscht wird.
[<=]

A_24768-02 - Schutz vor Replay-Attacken innerhalb eines Anwendungskontext

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS ein geeignetes Verfahren zum Schutz vor Replay-Attacken implementieren.
[<=]

A_24723-01 - Signieren der SessionID zu einem Anwendungskontext

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS zur Absicherung des SSO bei jeder Nutzerauthentisierung ohne Nutzerinteraktion im Authenticator-Modul die vom sektoralen IDP übertragenen SessionID zur laufenden Anwendungsinstanz mit dem zur SessionID auf dem Gerät des Versicherten gespeicherten Schlüssel signieren und an den sektoralen IDP übertragen.
[<=]

A_24748-01 - SSO-Unterstützung auf Anwendungsebene innerhalb einer APP

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS in seinem Authenticator-Modul eine Schnittstelle anbieten, der das Client-Modul bzw. Frontend eines TI-Fachdienstes die vom sektoralen IDP als Ergebnis des Pushed Authorization Request ausgestellte URI-PAR übergeben kann (siehe [gemSpec_IDP_Sek#Tabelle Ablaufbeschreibung App-App-Flow] Schritt 5). Die Schnittstelle MUSS als Ergebnis des Aufrufs den vom sektoralen IDP nach erfolgreicher Nutzerauthentisierung ausgestellten AUTH_CODE an das aufrufende Client-Modul zurückgeben.  [<=]

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

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS in seinem Authenticator-Modul sicherstellen, dass ein Authorization Request mit SSO-Anforderung von einem Anwendungsfrontend kommt, bei dem der Versicherte sich bereits authentifiziert hat, um SSO-Anforderungen von nicht berechtigten Anwendungen erkennen und ablehnen zu können.  [<=]

A_24749-01 - Validierung gegen Nutzerzustimmung

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS vor einer Nutzerauthentisierung ohne Nutzerinteraktion prüfen, ob für den Fachdienst, welche die Nutzerauthentisierung angefordert hat, die Zustimmung zum SSO-Verfahren durch den Nutzer vorliegt. Eine Nutzerauthentisierung ohne Nutzerinteraktion darf nur bei Zustimmung durchgeführt werden.
[<=]

A_25238 - Nachnutzung SSO für kasseneigene Dienste im FdV

Ein Anbieter eines sektoralen IDP KANN das Verfahren SSO innerhalb eines Anwendungskontextes für anbieterspezifische Dienste nachnutzen, wenn diese Dienste im gleichen Anwendungskontext genutzt werden und durch geeignete sicherheitstechnische Maßnahmen eine Beeinflussung der TI-Dienste ausgeschlossen werden kann. [<=]

A_25875-01 - Aktive Nutzerauthentifizierung im Anwendungskontext

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS vor einer Nutzerauthentisierung ohne Nutzerinteraktion prüfen, ob der Nutzer sich im laufenden Anwendungskontext bereits aktiv auf dem Vertrauensniveau gematik-ehealth-loa-high oder  auf dem Vertrauensniveau gematik-ehealth-loa-substantial zu welchem eine Einwilligung des Anwenders zur Nutzung dieses Verfahrens zum Zugriff auf Daten mit hohem Schutzbedarf vorliegt, authentifiziert hat. [<=]

A_27567 - Beschränkung der Fachdienst für ein SSO (befristet)

Der sektorale IDP MUSS sicherstellen, dass ein Single-Sign-On nur für im ePA-FdV gebundene Fachdienste erfolgen kann.
Hinweis 1: Die Client-ID (iss) der im ePA-FdV gebundenen Fachdienste können beispielsweise als allow-list im sektoralen IDP hinterlegt sein.  
Hinweis 2: Die Anforderung gilt für die zeitlich befristete Übergangslösung. Diese wird von einer ePA-FdV unabhängigen SSO-Lösung nach Abnahme durch das BSI abgelöst. [<=]

A_27568-01 - Widerruf und Reaktivierung der SSO-Präferenzen bei separater Authenticator-APP (befristet)

Ein Hersteller von sektoralen IDP, der ein SSO auf Anwendungsebene implementiert, MUSS sicherstellen, dass ein Nutzer Präferenzen zur SSO-Nutzung ausschließlich über sein Authenticator-Modul widerrufen und reaktivieren kann, sofern die verwalteten Anwendungen nicht Anwendungen der TI sind.
Hinweis 1: Die Anforderung gilt für die zeitlich befristete Übergangslösung. Diese wird von einer ePA-FdV unabhängigen SSO-Lösung nach Abnahme durch das BSI abgelöst.
Hinweis 2: SSO für TI-Anwendungen in einem ePA-FdV wird dort verwaltet und ist nicht Gegenstand dieser Anforderung.
Hinweis 3: Diese Anforderung soll sicherstellen, dass z.B. für Funktionen einer Kasse ein sicheres SSO ermöglicht wird.
[<=]

A_27570 - Annahme des Parameters Instance-ID im URI-PAR bei separater Authenticator-App (befristet)

Für eine SSO-Unterstützung auf Anwendungsebene bei separater Authenticator-App MÜSSEN Authenticator-Module von sektoralen IDPs für mobile Endgeräte den Parameter sso_instance_id  bei Vorhandensein aus einem URI-PAR-Aufruf entgegennehmen und auswerten können.  Wird eine sso_instance_id übergeben, so MUSS der Authenticator eine Nutzerauthentifizierung über Single-Sign-On beim sektoralen IDP initiieren.

Hinweis: Die Anforderung gilt für die zeitlich befristete Übergangslösung. Diese wird von einer ePA-FdV unabhängigen SSO-Lösung nach Abnahme durch das BSI abgelöst.
[<=]

A_15497-04 - Authenticator-Modul: PIN der eGK ändern

Das Authenticator-Modul von sektoralen IdPs gesetzlicher Krankenkassen KANN den Anwendungsfall "PIN der eGK ändern" gemäß TAB_FdV_156 umsetzen.

Tabelle 12: TAB_FdV_156 – PIN der eGK ändern

Tabelle 13: TAB_FdV_157 – Ablaufaktivitäten – PIN der eGK ändern

A_15498-04 - Authenticator-Modul: PIN der eGK entsperren

Das Authenticator-Modul von sektoralen IdPs gesetzlicher Krankenkassen KANN den Anwendungsfall "PIN der eGK entsperren" gemäß TAB_FdV_158 umsetzen.

Tabelle 14: TAB_FdV_158 – PIN der eGK entsperren

Tabelle 15: TAB_FdV_159 – Ablaufaktivitäten – PIN der eGK entsperren

A_26133 - Authenticator-Modul für Desktop-Plattformen: Integration in Anwendung

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen MUSS in die Anwendung integriert sein, die eine Authentifizierung des Nutzers erfordert. [<=]

A_26134 - Authenticator-Modul für Desktop-Plattformen: Authentifizierungsmittel eGK+PIN

Der Hersteller eines sektoralen IDP MUSS für sein Authenticator-Modul für Desktop-Plattformen ein Authentifizierungsverfahren mittels eGK und PIN über Kartenleser unterstützen. [<=]

A_26135 - Authenticator-Modul für Desktop-Plattformen: Unterstützung von Kartenlesern ab Sicherheitsklasse 2

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen MUSS es dem Nutzer ermöglichen, für eine Authentifizierung mit eGK+PIN einen Kartenleser einer höheren Sicherheitsklasse als Sicherheitsklasse 1 (Sicherheitsklasse 2 oder höher) zu nutzen. [<=]

A_26136 - Authenticator-Modul für Desktop-Plattformen: Hinweis bei Kartenlesern der Sicherheitsklasse 1

Falls das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen mit einem Kartenleser der Sicherheitsklasse 1 genutzt wird, MUSS das Authenticator-Modul für Desktop-Plattformen den Nutzer in einer für den Nutzer verständlichen Form darauf hinzuweisen:

• dass Kartenleser der Sicherheitsklasse 1 geringere Sicherheitsleistungen als Kartenleser der Sicherheitsklassen 2 oder 3 erbringen und welche handelsüblichen Kartenleser der Sicherheitsklassen 2 und 3 vom Nutzer für Desktop-Plattformen genutzt werden könnten,
• welche Risiken bei einer Nutzung von Kartenlesern der Sicherheitsklasse 1 für den Nutzer bestehen und welche Maßnahmen der Versicherte auf seinem Gerät treffen sollte, um diese Risiken zu verringern.

A_26137 - Authenticator-Modul für Desktop-Plattformen: Kartenterminal der Sicherheitsklasse 1: PIN-Eingabe

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen MUSS, wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird, die PIN-/PUK-Eingabe über ein angeschlossenes Eingabegerät entgegennehmen und in ein an die Karte adressiertes Kommando einbetten. [<=]

A_26138 - Authenticator-Modul für Desktop-Plattformen: Kartenterminal der Sicherheitsklasse 1: PIN-Eingabe Geheimnis

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen DARF die eingegebene PIN/PUK-Ziffernfolge NICHT im Klartext auf dem Bildschirm darstellen, wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird. [<=]

A_26139 - Authenticator-Modul für Desktop-Plattformen: Kartenterminal der Sicherheitsklasse 1: PIN-Eingabe Eingabefeedback

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen MUSS ein eingegebenes Zeichen einer Geheimniseingabe mit dem Zeichen "*" (Wildcard) quittieren, wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird. [<=]

A_26140 - Authenticator-Modul für Desktop-Plattformen: Kartenterminal der Sicherheitsklasse 1: PIN-Eingabe Validierung

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen MUSS, wenn das PIN-Geheimnis durch einen Anwendungsfall geändert werden soll und wenn ein Kartenterminal der Sicherheitsklasse 1 verwendet wird, ein eingegebenes, neues PIN-Geheimnis durch eine erneute Abfrage des neuen PIN-Geheimnisses verifizieren. [<=]

A_26141 - Authenticator-Modul für Desktop-Plattformen: Kartenterminal der Sicherheitsklasse 2: PIN-Eingabe

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen MUSS ein angeschlossenes Kartenterminal der Sicherheitsklasse 2 so ansteuern, dass ein Kartenkommando, das eine PIN-/PUK-Eingabe erfordert, an einem Kartenterminal um die Benutzereingabe ergänzt und anschließend direkt an die adressierte Karte weitergeleitet wird. [<=]

A_26143 - Authenticator-Modul für Desktop-Plattformen: Kartenterminal der Sicherheitsklasse 2: PIN-Eingabe Eingabefeedback

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen MUSS während der Abfrage einer PIN/PUK an einem Kartenterminal der Sicherheitsklasse 2 einen Benutzerhinweis zur PIN-Eingabe auf der Bildschirmanzeige des Kartenterminals ausgeben. [<=]

A_26144 - Authenticator-Modul für Desktop-Plattformen: Kartenterminal der Sicherheitsklasse 3: PIN-Eingabe

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen MUSS ein angeschlossenes Kartenterminal der Sicherheitsklasse 3 so ansteuern, dass ein Kartenkommando, das eine PIN-/PUK-Eingabe erfordert, an einem Kartenterminal um die Benutzereingabe ergänzt und anschließend direkt an die adressierte Karte weitergeleitet wird. [<=]

A_26146 - Authenticator-Modul für Desktop-Plattformen: Kartenterminal der Sicherheitsklasse 3: PIN-Eingabe Eingabefeedback

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen MUSS während der Abfrage einer PIN/PUK an einem Kartenterminal der Sicherheitsklasse 3 einen Benutzerhinweis zur PIN-Eingabe am Display des Kartenterminals ausgeben. [<=]

A_27501 - Authenticator-Modul für Desktop-Plattformen: Verpflichtende Verfahren zur Identifikation von Nutzern

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen KANN abweichend von A_22865* nur eGK und PIN zur Nutzerauthentisierung anbieten, wenn vom Nutzer ausschließlich eine Authentifizierung für Desktop-Plattformen verwendet wird. [<=]

A_27502 - Authenticator-Modul für Desktop-Plattformen: weitere Authentifizierungsverfahren

Das Authenticator-Modul eines sektoralen IDP für Desktop-Plattformen KANN weitere Authentifizierungsverfahren unterstützen. Insbesondere KANN der sektoralen IDP  die Authentifizierung des Nutzers mit seinem Authenticator-Modul auf dem Smartphone des Nutzers unterstützen (2-Geräte-Flow). [<=]

A_27503 - Authenticator-Modul für Desktop-Plattformen: Auskunft an Versicherte

Der Hersteller eines sektoralen IDP KANN abweichend zu A_22236* auf die Bereitstellung der Auskunft an die Versicherten verzichten, wenn Versicherte sich ausschließlich über das Authenticator-Modul für Desktop-Plattformen mit eGK und PIN authentisieren und keine GesundheitsID im sektoralen IDP persistent angelegt wird.  [<=]